SomeoneElseOSM
commented
1 year ago The rendering of amenity=parking_space was added as a bit of an experiment, and left in because it "didn't look too bad". Usage of this tag isn't especially widespread: https://overpass-turbo.eu/s/1rGh . Initially I added it because where individual parking was being mapped around new-build housing, it previously wasn't shown at all. Of the various options:
1) detecting "amenity=parking_space inside an amenity=parking" would need to be done in database code, not in lua, since the lua code (as currently implemented) doesn't have access to much spatial information, just tags. That's possible but something that I'd need to learn how to do, so it'd be some way down the list to look at.
2) detecting "amenity=parking_space that is part of a relation" could be done in lua, but it'd need a move to the "flex" backend of osm2pgsql first. That's very mature now, and would I'm sure be the suggested route to go if starting from scratch, but would be a significant change that would need scheduling in. As you mention, site=parking relations aren't used that much yet: https://overpass-turbo.eu/s/1rGj .
3) changing the rendering of all "amenity=parking_space " is doable as is, and dropping the "P" altogether, making it more dim, or replacing it with something else would all be options. One of these would definitely be the easiest to implement.
for example https://map.atownsend.org.uk/maps/map/map.html#19/52.87095/-1.62844
not sure how easy this is to do, potentially could make it easier by ignoring parking spaces that are part of a site=parking relation although it's not widely used