Vorab: Ich habe mich mit dem Indoor-Mapping bisher kaum beschäftigt.
Bin hierüber gestolpert: C&A befindet sich auf zwei Stockwerke, die beiden Ladenflächen wurden jeweils als Fläche eingetragen (EG, 1. OG). Soweit klar. Nun wurde an beide Flächen auch shop=clothes, name=C&A etc. getaggt. Also die POI-Daten. Damit wäre aber doch die One feature, one OSM element-Regel verletzt und alle POI-Daten wie Öffnungszeiten müssten doppelt gepflegt werden.
Ein POI-Node mit level=0;1 wäre zwar richtig, aber dann verliert man den Bezug zu den Flächen. Wie macht man es richtig, wenn man die Flächeninformation beibehalten möchte? Eine site-Relation als POI-Objekt mit beiden Flächen als Member?
Da sich die Flächen überlagen werden Dir da allerdings alle Validatoren auf rot springen.
Das OSM Datenmodell ist hier leider an seinen Grenzen.
Ich würde es einfach so lassen. Wenn man die beiden Flächen zusammenfassen möchte, halte ich eine site-Relation für ok (die POI Infos an den Einzelflächen dabei NICHT löschen).
Warum nicht? Dann wären die POI-Daten an drei Objekten redundant vorhanden.
Kannst Du das begründen? Es handelt sich doch um ein Geschäft. Das sollte in OSM durch ein Objekt repräsentiert werden. Würdest Du es auch als richtig empfinden, wenn man pro Etage ein POI-Node mit den shop-Daten einträgt?
durch die unterschiedlichen level-Angaben überlagern die sich ja nicht wirklich, wenn die Validatoren das nicht verstehen kann man ein Ticket machen, dann verstehen sie es vielleicht beim nächsten Mal
Das Thema kommt bei Diskussionen über Indoor-Mapping immer mal wieder auf. Die Lösung, auf die es meinem Eindruck nach hinausläuft: Ein neu zu erfindender Relationstyp mit beiden Flächen als Member.
Existierende Relationstypen passen alle nicht so wirklich. Die Regeln für Multipolygone verbieten eindeutig, dass sich die 2D-Flächen überlappen, und Tags an den Member-Ways (wie eben z.B. level) haben aus guten Grund keinerlei Bedeutung für das vom Multipolygon beschriebene Objekt.
Bei site ist es weniger offensichtlich, einfach weil site so vage definiert ist dass man alles oder nichts darunter verstehen kann. Aber diese konkrete Konstruktion, dass man level-Tags an den Einzelflächen hat, die die Ausdehnung auf dem jeweiligen Stockwerk beschreiben, ist schon speziell und unterscheidet sich m.E.von üblichen site-Relationen.
Aus meiner Sicht wäre daher die sauberste Lösung eben ein komplett neuer Relationstyp (type=multilevel_feature?) für diesen konkreten Anwendungsfall.
