Falk Zscheile schrieb: >> Der Notlösungen sind >> mit 2 bekannt: Trennung mit Semikolon. >> amenity=toilets;shower (wird quasi von keiner Anwendung erkannt/ausgewertet) > > Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese > Variante?
Ja: Es ist schwerer auszuwerten. Außerdem: Spätestens, wenn du einem der Dinge noch Attribute geben willst, funktioniert dein System nicht mehr. Genauso wenig kannst du z.B. mit den kürzlich vorgeschlagenen Etagen-Relationen das Restaurant in den ersten Stock setzen. Darum: Nimm zwei getrennte Nodes, ggf. innerhalb des selben building. Damit ist zwar die Information "befindet sich im selben Gebäude" schwerer zugänglich, aber die wichtigere Basisinformation leichter zugänglich. Und was ist wohl der wahrscheinlichere Anwendungsfall für eine 0815-Anwendung: "Gib mir eine Liste der Gebäude, die sowohl eine Toilette als auch eine Dusche enthalten" oder "Wo gehts zur nächsten Toilette"? > Je detaillierter man zukünftig arbeiten wird, desto häufiger wird man > Gebäude haben, die mehrere Eigenschaften besitzen, die sich nicht ohne > Tricks kombinieren lassen. Das Gebäude hat nicht mehrere Eigenschaften, sondern enthält mehrere (mehr oder weniger getrennte) Einrichtungen. Und so würde ich das auch mappen. Schon verschwinden alle potentiellen Probleme mit Zusatzattributen und bei Auswertungen. Dieser Gedanke, das im gleichen Gebäude liegende oder am selben Laternenpfahl hängende Einrichtungen sich einen Node teilen müssten, macht nur alles unnötig kompliziert. "Hängt am selben Pfahl" ist eine in der Praxis unwesentliche Information, für die man nicht das Tagging verkomplizieren sollte. Wenns wirklich interessiert, kann man ja eine Relation "same_pole" machen. ;-) Tobias Knerr _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
