Talk:Tag:amenity=parking space

From OpenStreetMap Wiki
Jump to navigation Jump to search

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. -->
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)

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)


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?

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)