I’m trying to solve for the unique way the Merseyway Shopping Centre in Stockport has developed - a series of buildings with bridges between them, which connect two multi-storey car parks with rooftoop car parks in between. The existing mapping was clearly done remotely based on aerial photos and doesn’t properly connect up, creating a sort-of patchwork of parking aisles on top of all the shops and no continuity across (the only advantage to this monstrosity).
Are either of these approaches “correct”? It feels wrong to mark car parks as “rooms”, but it also feels wrong to just dump two polygons on top of each other.
(I’m working my way towards the part of the car park above Adlington Walk, which is a multi-story that really needs the service roads mapped on both levels to reflect the fact that all of this is connected together. I’m hoping that by learning how to do the first two islands I can combine that knowledge to complete the map )
My first instinct was to extend relation 5503219 should be extended to include the other rooftop bits, but I don’t think touching outer rings really work. They might be something that could be grouped under a site relation though?
It looks like in my clumsy attempts to do the (much smaller) Eccles Precinct parking over a decade ago I just left the multi-storey without a building tag. Someone has since added one, but I think it should really be merged into the rest of the structure as a building:part with the relevant min and max levels.
If they’re part of a building structure I think they should have level tags in addition to the layer tags. I’m not really sure how level tags are meant to work on rooftop lanes etc, but I’ve tended to assume they should have the same level tag as a stairwell door would have to allow access to that feature.
From your description I think the one above Joseph Joseph should probably have a building:part=parking tag with a building:min_level tag set to exclude the retail portion (which might have its own building:part=retail tag). If there are other ‘rooms’ carved out of the Redrock car park for ticket machines, lifts, stairs etc, then I think that might be better as a building:part than a indoor=room too? Especially if it has the ‘feel’ of you just being in a multi-storey car park until you descend into the retail space.
Here, only the shape of the parking is given, perserving the clarity, but at the extent of the parking details. Not saying it’s a good solution, but it’s an option.
The problem is that some of the parking aisles and service roads are visible from the aerial imagery, so someone will come and draw it in again. In fact I suspect I’d get pushback for deleting the current parking aisles.
A hack is to prefix the keys please_do_not_tag:highway=service. Really a hack, so the next guy willing to add the road network would know it’s not welcome.
They exist and they’re accessible, so I don’t think this is a good solution. They are something that I think is perfectly in scope for OSM, they’re just awkward with the current tools and especially with the lack of rendering support in the major mobile navigation apps. But then the apps won’t feel the need for better display of stuff on multiple levels unless we start mapping the details.
If all we can see is the rooftop lanes then I tend to think it’s fine to trace them in disconnected until someone has the chance to check how they connect up.
I’ve tried something similar - the main thing I learnt was to use level=n in place of layer=n. Using a browser such as OpenLevelUp! shows the effect of the levels.
)