Ein Gebäude, viele amenity, wie taggen?

Hallo Leute,

ich habe gerade mit andreas eine diskussion am laufen und mich würden nun noch andere meinungen interessieren.

Wir haben ein Gebäude, darin befinden sich ein restaurant und eine alpine_hut, also zwei amenity. Theoretisch wäre es ja möglich, dass sich noch eine dritte darin befindet.

Ich tagge nun das gebäude mit den eigenschaften des gebäudes, adresse, building, usw.
Nun noch zwei nodes in das gebäude, jeweils mit den eigenschaften einmal des restaurants, einmal mit den des alpine_hut.

Andreas meint nur einen node zusätzlich mit allen eigenschaften erfassen zu wollen, restaurant und alpine_hut zusammen an den separaten node.

Ich finde das nicht konsequent. Denn bei einem großen Gebäude mit vielen Geschäften, einem Einkaufszentrum eben, erfasse ich auch ein Gebäude und viele separate nodes, jeweils für die Geschäfte je einen. Das ziehe ich nun auch bei den Gebäuden im Gebirge, also bei den Berghütten oder ähnlichem durch.

Nun die Frage, wie ist es richtig, wie wird es von der Masse gemacht.

Warte auf Eure Antworten

Ich mache das auch immer so wie du das gemacht hast, will da aber auch nicht für plädieren, dass es der Weisheit letzter Schluss ist (keine direkte Zuordnung zu Adresse). Bis jetzt sehe ich da aber auch keine Vorteile von Andreas Idee, aber vielleicht übersehe ich da was?

Ich mappe auch immer ein eigenen Node je Einrichtung, da sich oft die Details sonst nicht trennen lassen, bspw. Telefonnummern oder Namen.
Aber auch in Fällen, in denen sonst alles identisch ist, tendiere ich meistens zur Multi-Node-Lösung, da leider keinerlei Anwendung mit Mehrfach-Werten (foo=bar;baz) klarkommt.

Für die Adress-Zuordnung hätte ich allerdings auch gerne eine Lösung.

Separate Nodes im Gebäude sollten problemlos gehen, zumindest solange die verschiedenen Einrichtungen nicht das ganze Haus an sich darstellen, dann ist es eher eine Notlösung. Ich mappe auch separate Nodes für alles.

Hallo beisammen, ich bin der angesprochene Andreas

Ich finde den Thread-Titel etwas ungünstig, da es NICHT um mehrer Amenities innerhalb eines Buildungs ging, sondern um unterschiedliche Attribute ein und desselben Objekts (Selbe Stühle, Selbes Essen, Selbe nette Bedienung, selber Name, Selbe Preise, Selber Koch,…).
Hier ein betroffenes Gebäude, bei dem ich die Attribute von 1+2 auf 3 hinzugefügt habe und 1+2 danach löschte. Ursprünglich hatte das Gebäude bereits die Attribute Restaurant und alpine_hut (http://www.openstreetmap.org/browse/way/83122430/history). Erwin hatte die beiden Attribute als Nodes ausgelagert, was ich aber nicht notwendig/sinnvoll finde und Suchenabfragen der zusammengehörigen Attribute für die Programme unnötig verkompliziert (z.B. sollen opening_hours oder ele auf 1, 2, oder 3 eingetragen/gesucht werden.). “keep simple things simple”

Zugegeben: Mit eigenen Nodes sieht es zwar schöner aus, da mehr Icons dargestellt werden, aber sollen wir so taggen?
http://wiki.openstreetmap.org/wiki/Good_practice
Don’t place nodes in identically tagged areas just to see some icon appear on the map. The renderers will display icons on areas as well and there’s no need to have every parking-lot, soccer-ground etc. twice in the database.

Evtl. könnte man den Treadtitel etwas anpassen…
Andreas

In diesem Fall (innerorts) mit “normalen Besucherverkehr” würde ich auch Hotel und Restaurant einzeln taggen. Da nicht jedes Hotel auch “Verpflegung” anbietet. Und zeige ich nur das “Restaurant”, weiß ich nicht, dass man hier auch schlafen kann.

Für Hütten in den Bergen gibt es auch Vorschläge. Dort sind die Hütten auch unterschiedlich gerendert.

Die Mehrheitsmeinung (nicht meine übrigens…) in dieser Diskussion über Berghütten war, dass man bewirtschaftete Hütten daran erkennt, dass sie alpine_hut und restaurant zugleich sind. Sollte sich als richtiger herausstellen, dass man das getrennt erfasst, wirds schwierig: Man müsste “bewirtschaftet” daran festmachen, ob “alpine_hut mit restaurant in 10m Umkreis” oder “alpine_hut als Polygon mit restaurant im Inneren” oder “alpine_hut und restaurant als 2 Nodes im Inneren eines gemeinsamen building” zutrifft.

Nicht unmöglich, aber eher unwahrscheinlich, dass das jemand fürs Rendern oder Navigieren auswerten möchte…

Grüße, Max

@geri-oc: Die betroffenen Gebäude sind außerorts im Gebirge, wobei ich hier nicht unbedingt eine Unterscheidung machen würde und das Beispiel von maxbe zeigt, dass es für die OSM-DB schwieriger wird, wenn Attribute auf mehrere Notes verteilt werden. Ein Hotel mit Verpflegung in der DB zu finden, ist bei einem Node trivial, bei Verteilung auf mehrere Nodes wesentlich aufwendiger.

In diesem Fall bin ich für eine Kombination in einem Node bzw. am Gebäude. Es ist das selbe und Konflikte oder Mehrfachtags tauchen nicht auf. Wenn es amenity=alpine_hut und amenity=restaurant gewesen wären, hätte ich überlegen müssen, aber so ist das kein Problem…

Ersteres will ich nicht entscheiden Die zweite Frage kann ich beantworten: Die Masse nimmt einen gemeinsamen Node.

Eine Stichprobe in (10E,47N,13.25E,48.6N) liefert:

---- Nur Nodes betrachtet -----------------

alpine_hut:                            613
alpine_hut + amenity=restaurant:       180
alpine_hut + amenity="":               411
alpine_hut + amenity!=restaurant:       22 (*)


---- Nur Ways betrachtet ------------------

alpine_hut:                            377
alpine_hut + amenity=restaurant:       206
alpine_hut + amenity="":               150
alpine_hut + amenity!=restaurant:       21


---- Nodes mit building aussen rum -------

alpine_hut in building:                242
alpine_hut und restaurant in building:  98 (ein gemeinsamer Node)
alpine_hut und restaurant in building:  11 (zwei Nodes)

Die 11 Fälle, wo sich getrennte Nodes für Hütte und Restaurant eine Building teilen:

   node     |          name           
------------+-------------------------
 1594763356 | 
  483332841 | Geislhochalm
  475537079 | Schutzhütte rettenstein
  475561183 | Postalm
  470360565 | Wolkenstein
 1512747604 | Schwarzrieshütte
 1522699821 | 
  529384958 | Münchner Haus
  389786165 | Patscherkofelhaus
  481339299 | Falkaunsalm
 1244825387 | Rauthütte

Das Münchner Haus ist übrigens ein Fall, wo 2 Knoten sicher berechtigt sind. Das steht auf der Zugspitze und der Gipfel ist ziemlich vollgestellt mit Betrieben, bietet aber wenig Platz für eigenständige Gebäude. Darum gibt es dort einen Knoten mit “alpine_hut+restaurant” (Münchner Haus, betrieben vom Alpenverein) und einen weiteren Knoten “restaurant” (Gipfelalm, betrieben von der Bahngesellschaft).

In 6 Fällen hat einer ein Gebäude mit “tourism=alpine_hut” gezeichnet und die Gastronomie nochmal als eigenen Node (amenity=restaurant und tourism=‘’) reingesetzt, in 4 davon trägt aber auch das Haus ein Restaurant-Tag:

  way     |          name
----------+------------------------
 41745849 | Jagdhütte              (Gebäude= alpine_hut+restaurant)
 38024453 | Hintere Soile Alm 1325 (Gebäude= alpine_hut)  
 37652067 | Hirschberghaus         (Gebäude= alpine_hut+restaurant)
 83231867 | Berggasthof Hocheck    (Gebäude= alpine_hut+restaurant) 
 39216603 | Berndlalm              (Gebäude= alpine_hut+restaurant)
 39208344 |                        (Geislhochalm, Gebäude=alpine_hut, 1x restaurant-Node, 1x alpine_hut-Node)

Ich hoffe, ich hab keine Kombination übersehen…

Grüße, Max

(*) Die amenity!=‘restaurant’ sind ein buntes Gemisch aus “alm”, “alp”, “biergarten”, “shelter” und “drinking_water”.

Hi,
zumindest würde ich nicht mischen, sondern die addr: Tags immer an das POI heften.
Chris

Morgen Leute,

@andreas: gleich zu Beginn möchte ich kurz sagen, dass es mir im nachhinein leid tut, einen namen genannt zu haben. ich hoffe du hast damit kein problem und wie gesagt, es tut mir leid. unsere diskussion war und ist interessant

Aber der tread zeigt doch, es gibt unterschiedliche meinungen und unterschiedliche taggingarten und keine scheint doch wirklich falsch zu sein. wie ich dem andreas in unseren “privaten” korrespondenz schon geschrieben habe, taggt doch im Grunde jeder seinen zielen entsprechend. ich fahre mit dem rad durch die gegend und gehe viel in unseren schönen tiroler bergen wandern, suche versteckte radwege und unbekannte pfade und tagge diese im anschluss.

und dabei benutze ich mein gps, andere fahren mit einem navi durch die gegend. und da möchte ich nun mal sehen, ob es in einer hütte auch was zu essen gibt, ob sich dort auch ein cafe befindet, während man nebenbei dort auch noch schlafen kann. dafür brauche ich 2 symbole, die auf der karte dargestellt werden, denn tagge ich beides an einen node, dann funzt das nicht. auch bei der angesprochenen hütte.

so wie andreas das taggt, würde ich gar kein symbol finden, glaube ich, den die software wird sich wohl nicht entscheiden können, welches es denn nun darstellen soll.

bitte jetzt keine antworten, von wegen wir taggen nicht für renderer. ich habe auch schon eine anfrage gestartet, warum wir denn nun eigentlich mappen, guckst du hier:
http://forum.openstreetmap.org/viewtopic.php?id=15628.
und es geht immer um karten, karten, karten. also, solange es nicht als falsch bezeichnet wird, wenn ich zwei punkte erstelle, sondern eben “nur” als schwierig auszuwertend, werde ich zwei nodes erstellen, auch wenn sonst alles gleich ist, telefon, ele, öffnungszeiten, usw.
wir sammeln geoinformationen und der größte teil nutzt sie für karten und dort sind zwei symbole aussagekräftiger.

freue mich auf weitere beiträge

frage, was machtst du denn nun, wenn du mehrere POI in einem gebäude hast, mehrere geschäfte, lokale? dann müsste auch die adresse mehrfach eingepflegt werden und aktuell gehalten.

das wäre nun wieder nicht redundant!

und auch hier hat die software das problem, eine adresse einem poi zuzuordnen, genau so wie bei der hütte.

ich habe mich für eine taggingart entschieden und werde diese beibehalten, solange sie nicht als falsch bezeichnet wird.

Ja, aber da sehe ich kein großes Problem drin.

Na ja, in OSM gibt es kein richtig/falsch. Klar, ich kann natürlich darauf hoffen, dass Anwendungen die Zuordnung des POIs
zu dem Gebäude hinbekommen um die Adresse daraus zu ziehen, momentan ist mir aber keine bekannt.
Chris

Hallo Chris,

auch nichts besseres zu tun als OSM?

ich habe gelernt, dass datenbank eben redundant programmiert werden sollen, jede info sollte nur einmal erfasst werden. der bezug zu anderen daten, wo diese infos auch benötigt werden, wird auf andere weise erreicht, auf keinen fall durch das doppelte oder mehrfache erfassen der daten, das sollte immer vermieden werden!

ich finde es gibt schon ein richtig und falsch, oder besser ein richtiger und falscher. wenn über eine taggingart abgestimmt wird, dann ist es für mich richtiger, bzw. richtig und das andere eben dann falsch.

Stellt sich eher die Frage, warum die Render nur ein POI auswerten, dann wäre das Problem gelöst…

Das ist in der reinen Lehre durchaus richtig.
Allerdings wird gerne verschwiegen, dass die Redundanz-Freiheit mit sehr viel Aufwand auf der Ein-/Ausgabe Seite erkauft werden muss. Genauer gesagt, muss ein ungeheuerer Aufwand betrieben werden, um die Beziehungen vor dem Anwender zu verstecken.

Und genau das funktioniert in einem Projekt mit den unterschiedlichsten Editoren und Auswerte-Programmen einfach nicht.

Technisch betrachtet existiert zwischen unterschiedlichen Objekten in der Datenbank keinerlei Beziehung.
Es gibt nur ein Objekt mit:

• seinen Eigenschaften (Taggs)
• seinen Mitgliedern:
  o nichts im Fall von Punkten
  o Knoten im Fall von Wegen
  o Mitgliedern im Fall von Relationen

Mehrere POIs in einem Gebäude haben also in der Datenbank per se keine Beziehung zum Gebäude. Eine Beziehung muss also entweder per Relation in der Datenbank abgelegt werden oder in den Anwendungsprogrammen per Vorverarbeitung mit einer Funktion wie ‘liegt in’ aus den Geometrie-Daten erzeugt werden.

Edbert (EvanE)

Da hast Du völlig recht! Mir ist nun leider nicht bekannt, dass es eine Relation gibt, die Gebäude und POIs verbindet, oder bin ich da falsch?

Wenn nicht, dann heißt es entweder POIs am Gebäude festzumachen oder die Adressen bei jedem POI einzeln zu erfassen.
Was ist dann bei Einkaufszentren mit zahlreichen Geschäften?

Halte ich nicht für sinnvoll!