In the Danish forum, we are discussing how amenity=parking_space should be used. Mainly when mapping these at a charging station but it could also apply in other cases.
From the wiki, it seems (to me) that a amenity=parking_space is intended to be mapped as part of a larger amenity=parking (e.g. as individual spaces within a parking area). Also the wiki for parking_space=charging says “Within a parking area, create a second area surrounding only a single parking space.”.
However, in practice I often see cases (like disabled parking or charging stations) where spaces are mapped on their own, without any surrounding amenity=parking. So perhaps this is also accepted?
If independent mapping of a parking space is considered acceptable in some situations, would it make sense to clarify this in the wiki? From the discussion on the wiki page, it seems this issue has come up before, and that the current wording, where amenity=parking_space is not intended to stand on its own, has been maintained intentionally.
This is a question I also had when I first started mapping parking areas. The wiki is clear regarding the use of amenity=parking in this context.
I think it is more appropriate to follow the wiki’s guidelines, even if only a single parking space is mapped within a parking area. I don’t find this problematic at all; on the contrary, it is useful to differentiate between two types of objects that, although related, represent different concepts.
Personally, I find it helpful to know where parking areas are, regardless of the number of individual spaces, as this makes data downloads simpler and avoids having to handle each parking space separately.
I’m not sure I understand this. I’m not questioning whether it’s okay to map just one of many parking spaces (amenity=parking_space) in a parking lot (amenity=parking), but whether it’s okay to map parking spaces without any parking lot at all. Are you saying that it is?
I don’t think it’s a good idea to map a parking space without amenity=parking.
I consider it both compatible and useful to have both pieces of information on the map—parking areas and individual parking spaces—even in areas that contain only a single space.
Ah ok, that is also the way I read the wiki guideline but it seems not everyone does. At least I often see parking_space=disabled and parking_space=charging mapped without being part of a amenity=parking
If someone is only interested in the locations of parking spaces for people with disabilities or charging spots, adding just those to the map is fine. That’s likely why some mappers focus only on those details.
But for a full picture of the parking infrastructure in a neighborhood or city, more information is needed. That’s why, as a general rule, I find the wiki guidelines appropriate.
This may have as much to do with the language in the amenity=parking wiki as the amenity=parking_space wiki. The former says “a facility used … for parking motor vehicles, … , commonly known as a car park (British English) or parking lot (American English).
I would never refer to a single isolated parking space as a “car park” in normal language, so this tag would feel odd in that situation. This may be partly an English language issue. The Spanish article uses “estacionamiento / aparcamiento”, which I feel is more generic and can mean “parking” as well as “car park”.
To be clear, are you saying that a single parking spot would be mapped with both, or with only amenity=parking?
The way I understand from the different parking tags descriptions in the wiki, a single parking spot (room for 1 vehicle) should be mapped with amenity=parking_space when it’s a spot within a larger area of several parking spots (mapped as one amenity=parking area). If it’s a single spot by itself with no other spots around it should simply be mapped as amenity=parking (with capacity=1 I guess), i.e. no lower limit for the number of cars mapped with amenity=parking.
Again, this is my current understanding but I could very well be wrong, and therefore my question.
The english wiki page is quite clear about this and says that a single parking lot should be part of a parking area, even if the parking area does not contain more than 1 lot only.
In the latter case I understand this as a violation of the rule 1 object in reality = 1 feature in OSM, but that is how it is documented.
Fact is that there are many separate single parking lots mapped as amenity=parking_space without an additional amenity=parking so apparently it does not do any harm.
Especially when mapping street parking, it is not uncommon for an amenity=parking feature to have only a single or a few capacity. See the documentation on mapping street parking as separate areas.
An amenity=parking_space without surrounding amenity=parking may be simply ignored by applications in case of doubt. One could also call it a mapping failure. amenity=parking_space is intended to distinguish individual parking spaces within a (larger) parking lot, but not to characterize a standalone parking feature itself. Making the primary tagging of a feature dependent on its capacity sounds like a bad idea to me.
In the end, it’s the same as with other features like bicycle parking: We map these as amenity=bicycle_parking, regardless of whether it’s a single rack on the sidewalk or a large bicycle parking garage with infrastructure. The type and characteristics of the feature are determined by its tags. The same applies to (car) parking features: Whether an amenity=parking is a large surface parking lot or a single spot for charging electric vehicles is determined by its tags, e.g., parking (surface vs. lane/street_side, etc.), restriction (charging_only), or capacity (or geometric size).
A side note: Using the Parking plugin in the Every Door app I’ve noticed that it by default simply adds amenity=parking_space. So I guess it either assume the plugin will only be used for micro mapping parking lots (amenity=parking) or perhaps the issue of mapping isolated capacity=1 parking spots has not been taken into account.