Ja, aber da tut es ja im Prinzip auch voneinander getrennte Öffnungszeiten abtrennen. Aber grundsätzlich hast du schon Recht, eine bessere Datenstruktur wäre eine saubere Lösung.
Das ist aber nun gerade kein Problem, weil der Biergarten ja vor dem Gebäude ist, die Kneipe aber drinnen.
Also kann man zwei nodes mit verschiedenen tags platzieren.
Gruß,
ajoessen
Das reicht aber nicht, denn woran würde man z.B. die Kontaktdaten des “Ladens” hängen? Sie würden beide Nodes betreffen. Man hat hier verschiedene Objekte:
-
Ein Gebäude
-
Eine Kneipe in einem Teil des Gebäudes
-
U.U. weitere Läden, Wohnungen etc. in anderen Teilen des Gebäudes
-
Einen Platz vor dem Gebäude oder in einem Hof, der den Biergarten als Teil enthält.
Dann gibt es aber noch andere (nur logische) Dinge, wie den “Laden”, der sich aus Kneipe und Biergarten zusammensetzt. Diesen kann man eigentlich nur durch eine Relation zusammenfassen, denn es gibt kein real existierendes Objekt mit Ortskoortinaten, welches genau beides (Kneipe und Biergarten) umschließt. An diese Relation kann man dann z.B. die Kontaktdaten (wie z.B. eine Telefonnummer) hängen (oder eine Handelsregisternummer, einen Inhaber, eine Webseite, … um weitere Beispiele zu nennen). Ich halte es für falsch, die Relation dadurch aufzulösen, daß alle Attribute derselben redundant an beide Nodes gehängt werden. Dann stellt sich aber z.B. weiter die Frage, woran man die Adresse hängt: An das Gebäude (bzw. einen Eingangs-Node) oder an die Relation?
Ich glaube, daß in diesem Thread nun zwei verschiedene Themen behandelt werden, die man vielleicht besser trennen sollte. Denn die Abbildung von real existierenden Objekten mit Koordinaten und von nur logisch vorhandenen Dingen ist ein Thema, “vektorwertige” oder hierarchische Attribute ein anderes. Beides sollte sich immer sauber trennen lassen können.
Zum Thema Bäume von Schlüsselwerten:
Da hatte jemand die gleiche Idee: https://sotm-eu.org/talk?37
Ich wußte nicht, das es dafür sogar schon Beschreibungsprachen und Editoren gibt.
Der Nachteil dieser festen Hierachien in Bezug auf OSM steht da aber natürlich nicht:
Bei konkurrierenden Verwendungen muß man sich dann für ein Schema entscheiden. Was wenn man sich dann für das schlechtere Schema entscheidet, sei es weil man eine “dekokratrische” Mehrheitsabstimmung macht und das einfache aber schlechte Schema ab besten verstanden wird und es deshalb am beliebtesten ist? Evolution durch die Verwendung ist mit solchen starren und festen Zuordnungen nicht mehr möglich. Man muß muß sich da in der Mitte treffen: Baustrukturen ja, aber bitte flexibel!