I recently mapped out most of the parking lots at Royal Holloway (changesets 171661876 and 171662342 ). Using information provided to me by the university.
For these, I tried to follow Tag:amenity=parking - OpenStreetMap Wiki (site relation proposal) as it seemed to make the most sense for one car park divided, but I’m not sure I did it right.
Any criticism would be appreciated as I am still a little confused on how to do things the right way.
Thank you
ps: the cause of having two change sets is that the web editor started breaking on safari after i got to about 60 changed entities - text inputs would be oddly bugged - is this a known issue? (i used JOSM after i encountered that anyway)
Something that immediately jumps out is the use of polygons for roads, eg. way 260278863. In OSM, roads (highways) are almost always mapped as lines (ways) rather than areas (AKA filled polygon).
For way 260278863, way 9702864 is already doing the job. Likewise for way 260276904 it doesn’t need to exist because way 260276905 already marks the parking aisle. Parking 260276909 and 260276911 should be just one feature, as you did for 1428194669. Same for the third parking lot in the Car Park 13 relation.
The Car Park 9 relation and surrounding features have the same ‘service road as an area’ problem. Also, without looking at imagery, I wonder if the three street side parking areas that lie within the boundary of the Gowar building are correct. Are they within the footprint of the building so that they are covered by floors above? If they are, they should be tagged as covered=yes. If not, they should not be within the boundary of the building and instead follow the street parking scheme.
These features should indeed not be mapped using highway=* + area=yes, as they are normal linear roads.
It is possible (although not very commonly done), to map the extent of roads as areas in addition to the line. However, these additional areas should then be tagged using the key area:highway=*, not highway=*
I agree that these two polygons really appear to be part of the same parking area and that there should therefore only be one amenity=parking object.
To suggest a possible alternative which preserves the level of detail being mapped here: These ways could be retagged to amenity=parking_space, and a new area surrounding both of these and the parking aisle could be created and tagged as amenity=parking.
Almost the entire campus is mapped like that, by some previous contributor - all I did was change the boundaries to help them make a little more sense. I’ll go through and retag them as suggested by @Tordanik, and remove them where not necessary.
They are covered under the building, but also street side. I believe I already tagged them covered=yes. They look like this for reference:
One more question: For Car Park 9, I tagged each individual parking area with name=, and the relation also. For Car Park 13, I tagged only the relation. Which is correct?
It doesn’t render the name for Car Park 13, so I’m not sure if it’s correct, but also I could just be Tagging for the renderer - OpenStreetMap Wiki. Is there consensus on this?
I would not use a relation for Car Park 13 at all. Service roads are generally considered part of the parking area, so that area can be easily represented as a polygon surrounding all parking spaces and the section of service road between them.
In general, application support for type=site relations isn’t great and, more importantly, it is supposed to only be used where other data types aren’t suitable. I would therefore likely choose a multipolygon relation for Car Park 9 instead of a site relation (and then add the tags describing the parking area, such as amenity=parking + name=*, only to the relation, not to its members). This will change the rendering, though.
One question - when tagging Car Park 9, it is composed of two overground car parking areas and three underground parking areas. You say to add the tags onto the relation, but I struggle to see how I’d differentiate between those that are covered and not with this scheme.
A single area (whether it’s a closed way or multipolygon relation) cannot have separate properties for sections of it. So yes, at that point you would need a different way of mapping things.
Separate amenity=parking polygons with a “Car Park 9” site relation collecting all of them would be a possible way of modelling the situation. Application support may vary.
