|
I have noticed a situation on the map where somebody mapped all (or many) individual stores in a shopping mall, as areas representing the rooms. This shopping mall has some shops that extend over more than one level, connected inside the store with stairs or escalators. Currently, each level is mapped as a separate way (room) and the tags are on both. That is obviously wrong, violates the "one feature, one OSM element" rule, and causes maps to render those shops twice. What is the right way to map such a situation? Could I put the rooms into a multipolygon relation with "outer" role on both rooms, then put the shop tags on that multipolygon relation? Just so that people know what situation I am talking about: I am talking about the "Interspar" and "Müller" shops here, in the mall labelled "Wien Mitte - The Mall": https://www.openstreetmap.org/#map=19/48.20717/16.38546 Thanks in advance for any advice. |
|
My initial thought was simply to add a single indoor room with all levels tagged, eg for Interspar, level=0;1. But it's not that simple of course, because the level=0 and level=1 portions of Interspar have different footprints, with other shops ("New Yorker" and "Tom & White") occupying the non-overlapping areas. As far as I know, there's no generally accepted tagging standard for mapping multi-level shops like this Interspar that will both 1) accurately specify the footprint of each level, and 2) only tag a single element with shop=supermarket. Offhand a multipolygon feels wrong to me, and JOSM agrees -- you'll get an "Intersection between multipolygon ways" error. I think the situation would need its own sort of relation, akin to a 3D building relation. (Most 3D buildings don't use relations, but they're needed when upper floors of a building jut out larger than the footprint, especially if they overhang another building.) Note that there's a dedicated subforum for indoor mapping on the OSM forum site, and a similar question has been sitting unanswered for three years: https://forum.openstreetmap.org/viewtopic.php?id=63721 I think the right way forward is to bring this up on the tagging mailing list, and eventually write a proposal. This is difficult and often thankless work with no guarantee of a happy ending, so instead many mappers seem to have settled on this method of bending the "one feature, one OSM element" rule in these cases, in order to have something that looks nice on indoor renderers like OpenLevelUp: https://openlevelup.net/?l=0#18/48.20683/16.38484 Personally I just use shop nodes for these sorts of situations, rather than trying to map the exact floorplan with areas. Doesn't look as nice on OpenLevelUp, but simpler and less incorrect. (Btw, the Müller shop you mentioned is actually mapped as two different shop types: a chemist on level 1 and a department store on level 2. I have no idea if that's legit.) Thank you for your answer. Unfortunate that there's no standard way of doing this. I will simply keep it as is for now unless anyone else answers with a great idea how to keep the indoor mapping but prevent it from being rendered twice. I also noticed that the Müller shop is tagged in two different ways. It is certainly debatable how Müller stores should be tagged. This is a store that sells cosmetics, hygiene products, but also office supplies, board games, some simple electronics. There is no consistency among their other locations around Vienna either.
(29 Oct '21, 17:12)
goaned
Also of interest is this issue at the OpenLevelUp dev site: https://framagit.org/OpenLevelUp/OpenLevelUp/-/issues/79 It describes a mullti-level mall shop mapped as a site relation, with the shop tags on the relation and the room ways on each level as the relation members. (And it doesn't render; thus the open issue.) A lot of people hate site relations, though. IMO the most important goal of any solution would be to maintain compatibility with existing data consumers, who generally expect a shop to be either a single node, a single closed way, or a multipolygon. So I'd suggest something like a "feature_rooms" relation, which would include the traditionally mapped node/way/multipolygon feature in a "feature" role and the component rooms in "room" roles. Software that cared could associate the feature with the rooms and comprehend the indoor details, and meanwhile all existing software would work as before. But chicken-and-egg-wise, it doesn't feel like there's much point in contemplating a tagging solution if there's no interest from indoor mapping data consumers. And it appears that OpenLevelUp hasn't been updated in over a year.
(11 Nov '21, 03:18)
jmapb
|
