Einheitliches Tagging für POIs & App zur Kontrolle

Communities Deutschland (Germany)
21

Da bin ich anderer Meinung. Je klarer und eindeutiger ein Tagging ist, umso einfacher kann man das auch später per Bot oder anders automatisiert auswerten und umwandeln für eine evt. neue API.

Der ganze Lizenzwechsel war bzw. ist ja schon eine Heidenarbeit für Mapper und die Programmierer, die daran im Moment arbeiten. Alle paar Jahre den Mappern was vorsetzen, wo sie wieder eine Menge korrigieren müssen und evt. wieder Daten verloren gehen, wird nicht gerade viele motivieren auf Dauer. Und ich denke, dass ein Lizenzwechsel Kindergarten ist im Vergleich zu einer umfangreichen Änderung an der API.

Und da bin ich der Meinung, dass egal was man mit den Daten macht, ob Auswerten, Karten erstellen oder irgendwann in einen anderen Datentyp umwandeln. Je besser das Tagging ist, umso einfacher sind die ganzen Prozesse. Und genau deshalb sollten wir anfangen, etwas mehr auf die Qualität des Taggings zu achten, und dazu gehört meiner Meinung dass man für einfache POI Informationen keine Relationen auswerten sollte.

Und dabei soll eben meine Karte etwas helfen, die man später auch für andere POI Themen ausweiten kann.

http://osm.misterboo.de/education/

Wichtig, um die Karte auch vernünftig zu nutzen, ist aber erst mal eine eindeutige und genaue Definition im Wiki, die ich dann auch in meiner Karte verlinken kann.

Also nach der Art:

  • Wenn Du eine Schule findest die zusätzlich zur Fläche einen Node hat, übertrage die tags auf die Fläche und lösche den node.
  • Wenn du eine POI Fläche findest mit amenity=school, wo neben der Fläche auch zusätzlich die einzelnen Gebäude mit amenity=school getagged sind, dann lösche diesen Tag bei den Gebäuden
  • wenn du mehrere Gebäude findest, die zu der gleichen Schule gehören und alle jeweils mit amenity=school getagged sind, versuche eine Fläche um die Schule zu erstellen, gib dieser den tag amenity=school und lösche diesen Tag bei den einzelnen Gebäuden. Sollten die Gebäude schon info tags haben, übertrage diese an die neu erstellte Fläche
    u.s.w.

das heir ist z.B ein typisches Beispiel:

http://osm.misterboo.de/education/?zoom=17&lat=49.24675&lon=6.95777&layers=B00TT

Da sollten die Tags an die Fläche, der node sollte weg und bei den Gebäuden sollte amenity=school weg , evt. building=school an die Gebäude, so wie es im Wiki steht.

ebenso z.B. hier:

http://osm.misterboo.de/education/?zoom=17&lat=49.24653&lon=6.98506&layers=B00TT

Und hier noch ein seltsames Beispiel:

http://www.openstreetmap.org/browse/relation/1625056

Eine Schule als Multipolygon, outer die Fläche und inner die beiden Gebäude

22

Chris,

beides kann man machen. Die Fläche mit dem Tag, nur um die Raumnutzung zu dokumentieren. Den POI, wie man ihn in der Datenbank haben möchte, vermutlich mitten rein. Der Renderer wird dann dort die Zahl reinmalen, das Navi führt einen dann dort hin. Der Renderer der dann beides nimmt, also das Attribut von der Fläche und den des POI, ist dann selbst schuld weil er nicht gut genug generalisiert.

Mir gefällt das Mantra mit dem “nicht für Renderer mappen”, an dieser Stelle erscheint mir die Vorgehensweise jedoch inkonsequent. Aber soll meinetwegen jeder machen wie er/sie/es will. Um auf den Ausgangspunkt zurückzukommen: Eine App (was für eine überhaupt?) die irgendwas kontrolliert oder Vorgaben macht erscheint mir nicht sinnvoll.

LG,

-moenk

23

Ja, so läuft es momentan und das halbwegs gut. Die Meinungen ob es mit einem verbindlichen Regelwerk besser laufen
würde gehen ja durchaus auseinander. :wink:

24

Mondschein,

natürlich bekommt die Fläche die Tags. Und meinetwegen noch ein POI der die Tags hat gleich dazu. Machen wir bei Städten doch auch so. Soll der Renderer doch damit klarkommen, das ist doch nicht unser Problem.

LG,

-moenk

25

Ich sehe, das wird wieder mal eine Diskussion ohne echten Konsens … soll dann wohl so sein bei OSM. Jeder macht was er will. Wegen mir dann auch so :slight_smile:

26

Das kann man einfach nicht unkommentiert stehen lassen. Auch keine Lust das nun auszudiskutieren, das mit den Städten und boundarys ist eine vollkommen andere Sache und in dem Sinne eine Ausnahme. In OSM hat man noch nie Flächen und Nodes gleichzeitig eingestellt, das war schon immer verpöhnt und es ist auch in der Auswertung kein laxes “sollen die sich doch selber einen Kopf machen”. Wir machen kein Anti-Mapping für die Renderer genauso wie wir kein Anti-Mapping für die Router machen sollten (siehe Spur-Blödsinn).

Das ist ein grundsätzliches Problem von OSM, ich bin da aber voll auf der Seite von Radeln alles enger zu fassen. Vielleicht wird die Comm diesen Weg gehen, vielleicht auch nicht, sie bräuchte auf jeden Fall ein neues Regelset und einen neuen Aufbau, allerdings zweifel ich daran wenn ich die endlosen Diskussionen sehe.
Aber: Linux hat sich auch nie durchgesetzt oder nur in bestimmten Bereichen, warum solls mit OSM anders sein.

27

Hier ist übrigens ein Beispiel einer site relation, mit der sicher Mapper und Auswerter gut leben könnten

http://www.openstreetmap.org/browse/relation/1966465

Die Relation hat ein label node, an dem alle wichtigen tags dran sind.

Ich kann also problemlos die Schule finden, ohne die Relation auszuwerten. Viele site relationen haben die tags allerdings direkt an der Relation, an die kommt man dann nicht ohne aufwändige Relationen Auswertung.

28

Wobei der Aufwand nun bei site-Relationen auch nicht höher ist als bei Flächen.

Vorgehensweise in etwa so:

Suche alle Ways mit amenity=school und merke sich min. einen Node mit den Taggs des Weges.
Suche alle site-Relationen mit amenity=school und merke sich den Node mit der Rolle label und die Taggs der Relation.

Beides geht in einem Durchlauf.

Weiter geht es mit dem Parsen der Nodes. Suche alle gemerkten und alle mit amenity=school.

29

Das meinte ich ja auch … aber ich muss nicht die Relationen komplett auswerten.

Ohne Label Node, also wenn die Tags nur an der site relation sind, brauche ich ja noch einen Durchlauf für die ways und dann noch mal einen für die nodes, um an die Koordinaten der relation zu kommen. Wichtig wäre eben dass es in der relation einen node als Mitglied gibt, der alle tags des POIs besitzt. Und viele site relations haben eben keinen node mit den Infos.

30

Obiges funktioniert nur, wenn die Taggs alle an der Relation sind und der Node mit der role label leer ist.
Wenn das label komplett getaggt ist und auch noch das Gelände ein amenity=school hat musst du die Relation parsen, alle Wege merken, dann bei den Wegen schauen, ob einer mit amenity=school dabei ist und diesen dann auslassen. Ist aufwendiger, als mein Weg oben, weil du dreimal parsen musst.

In deinem Beispiel muss man einmal die Relationen parsen und sich Wege und label-Node merken, dann alle Wege und nach amenity=school filtern, wenn Weg-ID gemerkt wurde diese ignorieren und vom Rest min. einen Node merken. Dann alle Nodes parsen und nach amenity=school filtern und die gemerkten Node-IDs noch hinzu.

Macht 3mal parsen. Obiges kommt auf 2mal parsen.

31

Ich dachte wir mappen weder für die Renderer noch für die Auswerter!

Ich werde jedenfalls jede Information nur einmal in OSM eintragen.
Und wenn die “Schule” durch eine Relation definiert ist kommt amenity=school in die Relation.
Mit was die Relation verknüpft ist ist mir da schon wurscht da die Renderer das ja hiarisch abarbeiten.
Wenn der “Name” nicht in die Mitte der “Fläche” soll muß das Programm halt nach entrance suchen (wie mkgmap das schon macht)

Ich sehe bei den Renderern nicht das Problem der Auswertung, auch geht es recht flott.

Und hier wird ja verhemend gegen jedwede Reglementierung gearbeitet damit sind irgendwelche Einheitliche taggins schon gegessen!

Gruß
aus den schönen OSM-Daten-Wirrwar

32

Also verstehe ich das richtig: du bevorzugst die Tags an der Relation ?

Und nicht wie hier im Beispiel, wo alle Tags am label node sind ?

http://www.openstreetmap.org/browse/relation/1966465

Damit hätten wir dann auch schon wieder unterschiedliche Ansichten und da es eben kein Konsens gibt, müssen eh wieder beide Arten beachtet werden.

Meine Idee war ja, dass man durch den Label node die relation überhaupt nicht beachten muss, wenn man nicht will :slight_smile:

33

Mit dieser Idee liegst du aber falsch. Denn woher weißt du dass du den Weg mit der role perimeter beim Parsen der Ways nicht beachten darfst? Genau dadurch, dass du vorher in der Relation geschaut hast, dass perimeter und label zu einem Objekt gehören und somit nicht doppelt angezeigt werden sollten.

Ebenfalls wollte ich dir den Hinweis geben, dass das zusätzliche Parsen der site-Relation nicht aufwändiger ist, als würde man nur nach Nodes und Ways parsen, WENN die Taggs nur an der Relation sind.

34

Für was oder wen mapped ihr denn ? Aus Zeitvertrieb ? Ich dachte wir mappen, dass wir selbst oder andere mit den Daten auch etwas anfangen können. Da muss es doch logischerweise einen Dialog geben, und so ein Dialog manifestiert sich doch auch normalerweise dann in festen Regeln. Regeln in denen der Auswerter nachsehen kann wie er den Algorithmus für seine Auswertung schreibt und gleichzeitig Regeln für den Mapper, damit er weiß, wie er am sinnvollsten sachen Mapped, mit denen der Auswerter oder er selbst was anfangen kann.

Wenn es da keinen Dialog gibt, und ehrlich gesagt sehe ich diesen Dialog nirgends, dann ist die Chance groß, dass weder Mapper noch Auswerter so richtig gücklich werden.

35

Ich bin da flexibel … wichtig ist mir eine einheitliche Regel. Was nützt es mir denn als Auswerter wenn deine Idee die bessere ist, und trotzdem die meisten eben die tags an den label node schreiben.

Also das eigentliche ist: im Grunde ist es mir egal wie was gemacht wird, nur sollte es einheitliche Regeln geben.

site relationen mit den tags in der relation
site relationen mit den tags im label node
multipolygon relationen (müssen eh immer 3 mal geparst werden um an die Geometry zu kommen)
collection relationen

egal was du vorschlägst und egal ob das auch evt. leichter zu parsen ist, es nützt eh nichts da es nicht einheitlich ist und ich am Ende doch alle erdenklichen Taggings parsen muss.

Also nochmal: Fangen wir doch einfach mal an, ein einheitliches Tagging im wiki festzuschreiben. Zumindest bei den doch eigentlich trivialen Sachen wie den POIs.

Und im Wiki steht momentan eben nur : entweder Node oder Fläche mappen. Genau diese Info hat auch der Auswerter. Da aber die Realität von dieser Info erheblich abweicht und es dort alle möglichen denkbaren und undenkbaren Kombinationen von nodes, ways und relationen gibt, die aber nicht mal im wiki erwähnt sind, muss der Auswerter für jede Kleinigkeit erst mal eine hochkomplizierte Analyse machen welche Taggings es gibt und wie er diese alle in seiner Auswertung unter einen Hut bekommt.

36

Und wieder eine Diskussion um Kaisers Bart… :roll_eyes:
…wie immer ohne Konsens. :rage:
Meine (für mich) logische Lösung. Ein POI- oder was auch immer -tag kommt an das größtmögliche zusammenhängende Gebilde, für das diese Eigenschaft flächenmäßig oder räumlich zutrifft.
Am Beispiel einer Schule heißt das: amenity=school kommt an den Flächenumriss der auch den Schulhof, Lehrerparkplatz usw. beinhaltet. Darin liegende Schulgebäude bekommen building=school, das Wohnhaus des Hausmeisters bekommt building=house usw.

37

Und was wird gemacht wenn die Fläche durch eine Strasse geteilt wird? Kommt das amenity=school nur an die größer Flache oder macht man dann aus der Fläche ein Relation vom Typ Multipolygon das wäre zumindest konsequent.

Blos was machen Mappe die eigentlich keine Flachen eintragen sonder nur die Häuser von Bing abzeichnen?
Die müssten dann zumindest eine Relation erstellen in der alle Schulgebäude eingetragen sind damit amenity=school nicht zu häufig vorkommt.

Es kann halt nur so funktionieren dass der Auswerter alles Mögliche von Node über Weg zu Relation berücksichtigen muss.

38

Wie schon geschrieben hätte ich weder als Mapper noch Auswerter etwas gegen eine Site Relation mit einem Label Node mit allen relevanten tags wie hier in dem Beispiel:

http://www.openstreetmap.org/browse/relation/1966465

39

Meine Interpretation vom Proposal ist aber anders.
Hier sollten alle Informationen in die Relation und der Label Node ist nur um zu definieren wo der Name bzw. das Symbol gerändert werden soll.
Tags doppelt zu erfassen (in deinem Beispiel Name und Amenity) halte ich für verkehrt. Wie soll ein Runderer bei unterschiedlicher Bedatung wissen was verwendet werden soll?

Es ist aber im Endeffekt genauso wie mit den Highways. Jedem ist was anderes wichtig deswegen wird ein Highway nicht von Anfang an mit allen Informationen angelegt sonder sie kommen nach und nach mit durch andere Mapper hinzu.

Bei POIs ist es genauso. Die Information zu dem POI wird immer genauer.
Am Anfang ist es meist nur ein Node. Dann macht einer ein Fläche und später werden Einzelheiten erfasst die dann erst in einer Relation zusammengeführt werden müssen.

40

Nochmal: das war nur ein Vorschlag. Im Grunde ist es mir egal. Es gibt Mapper die haben viel mehr Erfahrung als ich. Es war nur ein Vorschlag. Der Kernpunkt ist ein einheitliches, dokumentiertes Tagging, an das sich Mapper und Auswerter halten können.

Solange es diese Einheit aber nicht gibt ist jeder Vorschlag eigentlich genauso gut oder schlecht, denn ich muss als Auswerter doch eh alle unterschiedlichen Taggings berücksichtigen.

Wenn denn eine Relation gebraucht wird bei den POIs, und das Tagging der Infos an der Relation als besser erachtet wird, dann ist das auch OK. Nur sollten wir das dann auch dokumentieren. Und zwar so genau wie möglich. Andernfalls können wir ewig weiter diskutieren und es wird nicht besser. Momentan sehe ich halt recht viel wildes Tagging bei den POIs.

Bisher ist die site ja nicht mal offizielles Tagging sondern nur ein inaktives Proposal

http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site