Talk:Tag:amenity=parking space

Discuss Tag:amenity=parking_space here:

---

amenity=parking backwards compatibility

Surely the amenity=parking tag should always be used for the wider area drawn around the whole car park? We can fanny around with detailed mapping parking spaces inside that area, as an optional level of detail, but the amenity=parking needs to be in place.... surely?

You reverted an edit by Dieterdreist which seems to relate to this.

I seem to be repeating a discussion that was had during the proposal: Talk:Proposed_features/parking#Reinvention of wheels, backwards-compatibility... but that discussion seemed to go off into irrelevant details. Surely it's quite straightforward. Are you proposing that the tag amenity=parking will be in place (as an area or just on a central node) or are you proposing something which breaks all of that?

In the conclusion to that discussion you (Flaimo) say "now that there is no double usage for the amenity=parking tag anymore, the two mapping stiles can coexists without problems". I would have thought the sensible approach is to say that the two must co-exist. The documentation should say... if you're adding details of parking spaces, you really must make sure you've started by tagging the car park as a whole using the conventional widely accepted amenity=parking tag.

-- Harry Wood 02:45, 18 June 2012 (BST)

it is just wrong. are you placing a node amenity=fuel inside a building which also is tagged as a gas station only because some programs can only evaluate nodes? or are you mapping bus stops twice only because most programs can't handle the new public transport scheme? no you don't.

then why map the same physical parking space twice. there was enough discussion about than in the RFC phase and there where more negative aspects to is, than advantages and that is exactly why it is not in the accepted proposal. "coexists" means either the one mapping scheme, or the other. --Flaimo 07:45, 18 June 2012 (BST)

Well no I agree you should definitely not map a amenity=fuel inside a building which also is tagged as a gas station. One feature, one OSM element.

But I don't think this is a case of mapping the same feature twice. I suppose it depends how you look at it, but I'd say a parking space is a detail inside, and part of, a car park. Would you not agree with that? Of course looking at it this way also has the small advantage that you don't break everything. :-)

But anyway I'm just noticing there's a bigger issue here. The Tag:amenity=parking currently also talks about the 'site' relation, and says "If you use such a relation to describe the parking lot, it should not be mapped a second time using amenity=parking". Which is bad for the same reasons.

- Harry Wood 15:56, 19 June 2012 (BST)

So if you map specific Rooms of a Building you would remove the building=yes? -- rayquaza 17:06, 20 June 2012 (BST)

if the proposal of mapping rooms says so, then yes. if it is not specified, then this would be a discussion point. in case of parking spaces it is explicitly noted, that you have to choose either the one or the other mapping scheme and therefore there is no ambiguity on what to do. --Flaimo 09:58, 15 November 2012 (UTC)

Your proposal also explicitly states "Therefore I wrote this proposal as an addition, not as an replacement, to the current mapping scheme for parking spaces." As well as "This new tagging scheme is not meant to replace amenity=parking." This definitely does not look like an unambiguous statement in favour of replacing the amenity=parking areas, quite the opposite. --Tordanik 11:25, 15 November 2012 (UTC)

that is a misunderstanding from your part. it explicitly refers to the scheme, in other word to the general concept, but not a single parking lot. --> https://wiki.openstreetmap.org/wiki/Proposed_features/parking#What_about_the_current_amenity.3Dparking.3F

it means that it doesn't render amenity=parking obsolete in general, but rather that you can map a parking lot either one or the other way, but not both variants at the same time, because that would lead to redundant data and problems for maps that evaluate both schemes. Therefore the latest change to the description page is actually misleading. --Flaimo 13:56, 15 November 2012 (UTC)

Davileci (talk) 16:05, 5 April 2023 (UTC)

Marking an exceptional parking space in the middle of street parking?

Here in San Diego, there are streets where a single space in front of a building is posted with a sign and a curb stripe as "disabled parking only" (i.e., holders of disabled-parking permits). These are not spaces in parking lots but parallel-parking slots in the midst of general street parking. There are many of them, and it seems like a useful thing to map them, so it seems natural to me to use a node tagged amenity=parking_space alongside the street for this situation. But the definition of this tag seems pretty clear that it's to be used only in a relation that ties together a wider parking area. So I'm not sure what to do with these. —Larry Gilbert (talk) 02:19, 11 February 2013 (UTC)

parking:lane

In my region a user maps amenity=parking_space next to a parking:lane tagged street. So the parking:lane is kind of double recorded. Do you think amenity=parking_space should be used in this connection? I cannot read anything about that at this wiki page. And I do not see how to connect these both objects while they are just next to each other - may be one could use a site relation.--U715371 (talk) 22:32, 17 January 2015 (UTC)

I agree that using both would duplicate the tagging and should be avoided. --Tordanik 11:30, 22 January 2015 (UTC)

Handicap parking?

Is there a way to tag handicap parking?

How about truck parking?

Is there any way to tag it correctly?

• hgv=designated Davileci (talk) 21:20, 14 October 2023 (UTC)

parking_space=disabled ?

The question has been asked here .. 10k occurrences looks like a lot when amenity=parking_space has just about 30K. Using access:disabled as suggested in the proposal might also appear outdated as the trend would probably be access:conditional ? RicoZ (talk) 18:17, 14 January 2019 (UTC)

Suggested use of a site relation

Is this actually sensible here or is it just wasting everyone's time? From a rendering perspective I've looked at using different types of relations (including type=site) but have never managed to do anything useful with them. Can anyone think of an example that actually consumes site relations for any purpose? SomeoneElse (talk) 10:19, 29 September 2019 (UTC)

For typical parking areas it's probably a waste of time. When you can draw an amenity=parking area that contains all the individual parking spaces belonging to it (and no others), that should be sufficient. In fact, Relation:site says as much, contradicting the guidance on this page.

It may be more convenient for data consumers to have a relation, but I'm not a fan of asking mappers to spend manual effort on something that can be reliably automated. So I'd support dropping the requirement to use a site relation except where things would otherwise be ambiguous. --Tordanik 11:35, 3 October 2019 (UTC)

Unsigned Integer

What does "Unsigned Integer" mean as the possible value for capacity? Could we use another word here? --S8evq (talk) 09:34, 29 December 2019 (UTC)

Fixed. How's this? JeroenHoek (talk) 09:44, 29 December 2019 (UTC)

OK, thanks --S8evq (talk) 12:10, 29 December 2019 (UTC)

Using "positive" is an improvement, but the word "integer" is more specific than "number", so I'd like to bring that back (or use "whole number" if that feels more accessible) to make it clear that capacity cannot have fractional values like 1.5. --Tordanik 22:43, 19 January 2020 (UTC)

parking=lane and parking=street_side

Is there a common/official/... way of combining this tag with parking=lane and/or parking=street_side? I've noticed that some of the street parking in my city has been mapped by space, and want to tie this to the (here) more common parking:lane=* tags. Rostaman (talk) 22:40, 31 October 2021 (UTC)

Pretty much as you see documented on parking=street_side. When individual parking spaces are mapped, you would have a street_side or lane element surrounding it. These are typical examples of how to map them. Mapping the individual parking spaces is optional of course, and in many cases the parking=lane or parking=street_side area does not even have individual parking spaces. --JeroenHoek (talk) 07:47, 1 November 2021 (UTC)

Adjacent parking spaces

I can't find an answer to the question of whether it's better to map the spaces separately or with common points and lines if they are adjacent. Is there a better way? I see that the image in the wiki is more about separate, but in the example maps they are adjacent. I think adding this answer to the main article should help. --Martinligabue (talk) 21:08, 16 August 2023 (UTC)

In my opinion, amenity=parking and amenity=parking_space should share nodes where possible. I guess in the schematics the lines are drawn somewhat staggered only for visual clarity. --Martianfreeloader (talk) 20:23, 17 August 2023 (UTC)

Make clear that mapping groups is also fine

Currently it treats mapping group of spaces as invalid with some exceptions. I think it should be weakened and current claims are too strong Mateusz Konieczny (talk) 10:28, 7 November 2023 (UTC)

Wouldn't a group of parking spaces be a amenity=parking ? -- Martianfreeloader (talk) 20:26, 7 November 2023 (UTC)

Not necessarily. Here https://osm.org/way/790204562 I mapped one part of a big parking lot with one amenity=parking_space which has ref "A". Otherwise I would have no way to mark zones A, B, etc. Mapping individual spaces wouldn't make sense here, as this is not a public parking lot anyway. So I agree with Mateusz that such mapping shouldn't be forbidden. maro21 21:22, 7 November 2023 (UTC)

I see, thanks. Then another stupid question: Isn't this already implicitly documented as permissible in the explanation of the capacity=* key? (the way you did in your example) -- Martianfreeloader (talk) 21:29, 7 November 2023 (UTC)

Yes, it is! maro21 22:51, 7 November 2023 (UTC)

It's not helpful to use "Mapping individual spaces wouldn't make sense here, as this is not a public parking lot anyway." to avoid the problem. The requirements depends on how amenity=parking is interpreted, Unfortunately while parking=surface etc is a carpark, parking=street_side is specified as divisible similar to amenity=bicycle_parking . Either missing a higher level to group amenity=parking , or a level in between to divide a amenity=parking and group amenity=parking_space .
—— Kovposch (talk) 07:12, 8 November 2023 (UTC)

I raised this in Proposal talk:Parking=street side#Intermediate level . But could use eg area:highway=parking ?
—— Kovposch (talk) 07:06, 8 November 2023 (UTC)

Recent edit: "clarify, this tag does not require amenity=parking"

@Dieterdreist: This change seems at odds with the general agreement that amenity=parking_space entities:

[are] an addition, not a replacement, to mapping a whole parking lot with amenity=parking. (First line of the article, part of the proposal too.)

Could you clarify your 'where applicable'? The current wording is vague and confusing. ---JeroenHoek (talk) 09:41, 6 December 2023 (UTC)

I restored the text to match the description in the lede. --JeroenHoek (talk) 19:58, 14 December 2023 (UTC)