Ein Objekt mit mehreren amenities - wie eintragen?

Hi, ich trage z.Zt. Restaurants, Cafes etc. in meiner näheren Umgebung ein. Da stellt sich für mich nun erstmals die Frage, wie ich mit Objekten verfahre, die mehreren amenities zugeordnet werden können, z.B. Restaurant & Biergarten? Macht man da zwei Einträge oder welche Lösung ist üblich?
robart

Hallo,
ich stehe vor dem selben Problem und behelfe mich damit z.B. bei einer Bäckerei mit Caffee eben zwei Notes nebeneinander anzulegen.

Ich wurde auf der Mailingliste darauf hingewiesen dies mit Semikolon zu lösen.

amenity=restaurant;biergarten
restaurant:cuisine=german
biergarten:capacity=100

Danke für den Hinweis, werde ich auch so machen.

Ganz schlechte Idee, damit erreichst Du nur, daß gar nix davon auf irgendeiner Karte auftaucht. Es gibt meines Wissens momentan keinen Kartenrenderer bzw. überhaupt keine Software, die in der Lage wäre sowas auszuwerten und auch kein Konzept oder Einigkeit sowas einzubauen - geschweige denn genau so.

Mach lieber zwei Nodes, die werden wenigstens erkannt und schlimmstenfalls aus Platzgründen einer ausgeblendet.

Das funktioniert leider ganz und gar nicht. Es ist dem menschlichen Leser zwar vielleicht klar, wie es gedacht ist, aber eine Software liest daraus eine amenity vom Typ “restaurant;biergarten” (hm, kenn ich nicht), einen Key “restaurant:cuisine” (hm, kenn ich nicht, kenn nur “cuisine”) etc.

Ich halte in der Regel auch nichts davon, Dinge als einen Node zu repräsentieren, die bei einer Zeichnung als Fläche nicht die selbe Fläche einnehmen würden. Daher: Zwei Nodes dafür, nicht nur aus Gründen der einfacheren Auswertung.

Für die Zukunft sollte man für diesen Fall m.E. eine Relation etablieren (nach Art der site-Relation). Die würde zwar auch nicht von jeder Software ausgewertet werden, aber das Ignorieren der Relation würde zu einem viel besseren Ergebnis führen als das Ignorieren der Semikolon-Syntax.

Natürlich funktioniert das nicht, ist ja nirgends implementiert. Allerdings wenn man nur das taggt, was Software und Renderer anzeigen/bearbeiten, dann wäre die OSM-Datenbank ziemlich leer. Nicht zu vergessen, daß es ziemlich simpel sein sollte, der Software zu sagen, bei einem vorhandenen Trennzeichen ein Knoten mehrfach zu führen und die Eigenschaften richtig zuzuordnen. Letzteres klappt ja schon bestens bei Straßenregeln (maxspeed:hgv, maxspeed:psv, access:hour_on etc.)

Restaurant-Biergarten ist ja auch ein schlechtes Beispiel für dieses Thema. Ich tagge dies normalerweise mit amenity=restaurant und biergarten=yes, denn in meiner Gegend nehmen beide in aller Regel die selbe Fläche ein und der Biergarten nimmt eine untergeordnete Rolle ein.

“Ganz schlechte Idee, das funktioniert leider ganz und gar nicht.” :wink: Viel besser heißt, mehrere Knoten/Flächen für ein und das selbe Objekt, richtige “Knotenwolken” für zB Kaufzentren und mehrstöckige Gebäude, eine weitere Ebene der Abstraktionsebene durch Relationen?

Mit den Semikolons führst Du eine zusätzliche Hierarchiestufe ein, die von JEDER Software extra geparst werden muß. Alle Editoren, alle statistischen Auswertungen, alle Kartengeneratoren, alle Renderer. Damit hängst Du die Mindestanforderung für jede Software ein gutes Stück höher. Und selbst wenn alle Leute, die ein Tool implementieren, sich gerne die zusätzliche Arbeit machen wollen, fehlt immer noch ein klares Konzept, wie genau das zeug aufzubauen ist. Da gibt es das Modell mit Semikolons, es gibt einen Vorschlag mit Arrays und Alternativen was Prefix und was Postfix ist. Also wird es überall anders funktionieren und das Ergebnis ist Chaos. Und wer weiß, vielleicht beschließt man ja doch noch, eine echte Hierarchiestufe für sowas einzuführen.

Es würde mich auch interessieren, wie Du auf die Idee kommst, maxspeed:hgv würde “bestens klappen”. Alle Programme und Regelsätze, in denen ich bisher rumgewurschtelt habe, ignorieren ein solches Tag samt und sonders.

Das ist überhaupt nicht simpel. Es bedeutet zum einen, dass Software nicht mehr auf exakte Strings vergleichen kann, was bei Datenbanken o.ä. normalerweise ein beträchtlicher Effizienzverlust ist. Weiterhin muss die Software mit der unterschiedlichen Reihenfolge und womöglich unterschiedlichen Leerzeichensetzung klarkommen. Wenn du dann noch “Attribute” mal zur einen, mal zur anderen amenity zugeordnet haben willst, wird das noch um einiges schwieriger.

Aha. Es klappt bestens? Bei welcher Software denn?
Nicht, dass ich dort was gegen die Vorgehensweise hätte (ich habe dieses Proposal ja selber geschrieben) – das liegt aber daran, dass ich, obwohl das schon seit Monaten diskutiert wird, keine Variante gefunden habe, die nicht entweder erweiterte Tag-Syntax oder Relationen für jede Beschränkung braucht. Es ist also eigentlich keine schöne Lösung, aber wahrscheinlich das kleinste Übel.

Ok, ich kenne deine realen Beispiele nicht, aber es fällt wieder auf, dass mit dieser Lösung jede Biergarten-Karte sowohl nach amenity=biergarten als auch nach biergarten=yes suchen muss. Immerhin funktioniert die Haupt-Amenity noch. Vielleicht haben wir hier auch unterschiedliche Begriffsvorstellungen (wenn ein Restaurant mit dem Biergarten identisch, aber eigentlich kein Biergarten ist, dann ist es doch einfach ein Freiluftrestaurant?).

Es funktioniert im Kern in sämtlichen Renderern, Namens- und Routenzielfindern, Spezialkarten (alle amenity=x rendern), in Tagwatch …

Nein, nur mehrere Knoten/Flächen für Objekte, die zueinander gehören und/oder einander enthalten. Ein Geldautomat und das Einkaufszentrum, in der er steht, sind nicht dasselbe Objekt. Ein Restaurant und der angeschlossene Biergarten sind nicht dasselbe Objekt.

Richtig. Was auch gleich die Chance für Stockwerksangaben oder, z.B. bei Passagen, grobe Darstellungen des Gebäudeinneren gibt.

Deine Semikolon-Schreibweise ist genau so eine Abstraktion, du erzeugst “virtuelle” Objekte, erkennbar unter anderem daran, dass man sie separat attributieren können soll. Der gemeinsame Node entspricht in der Funktion der Relation, er hält nämlich die (virtuellen) Einzelobjekte zusammen – mit der zusätzlichen Schwäche, dass er dabei auf die Möglichkeit verzichtet, durch Rollen eine Semantik (“enthält” oder so was) ausdrücken zu können.

Der Vorteil an der Relationenlösung ist, dass die meisten Anwendungen völlig mit dem Standort jeder einzelnen Einrichtung zufrieden sind, und daher auf die zusätzliche Komplexität verzichten können.

maxspeed:hgv, maxspeed:psv, access:hour_on usw. funktioniert nur, weil diese Tags explizit festgelegt wurden. Sie folgen keinen Regeln, die die Software auswerten könnte. Es gibt einen Thread, wo wir schonmal versucht haben genau solche Regeln zu definieren: http://forum.openstreetmap.org/viewtopic.php?id=1284

Mein Lösungsvorschlag für mehrere Objekte auf einem Node wäre, für jede Jedes Objekt eine Relation zu erstellen, die entsprechend getaggt ist, und nur diesen einen Node als Mitglied hat.

Tordaniks Vorschlag würde natürlich auch funktionieren…