Einheitliches Tagging für POIs & App zur Kontrolle

Ich würde gerne eine App erstellen, mit der man bestimmte Themen visualisieren und kontrollieren kann.
Als Test habe ich mir das Thema Education ausgesucht, also tags mit amenity=kindergarten, school, college, university, education

Ziel soll es sein diese einfach zu visualisieren und evt mal ein einheitliches Taggingschema auszuarbeiten, das auch entsprechend
gut dokumentiert ist im Wiki.

Einfach bedeutet: der Datenbestand soll aktuell sein und weltweit auswertbar sein. Eine eigene Infrastruktur fällt da schon mal weg,
denn für eine weltweite Auswertung fehlt mir die Hardware.

Dank Overpass API ist das aber problemlos möglich.

Hier mal eine erste Testversion der App (funktioniert mit modernen Browsern, aber nicht mit dem IE 6-8 - meine Popups funktionieren dort nicht)

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

Ausgangspunkt für Anwender die so etwas auswerten möchten, sollte eigentlich das Wiki sein, hier z.B. zum Tagging amenity=school

http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dschool

Setze einen Punkt Node oder zeichne die Fläche Area des Schulgeländes (die Schulgebäude können innerhalb dieser als Flächen mit building=school gezeichnet werden)

Wenn man sich als Auswerter danach richten könnte, wäre das gut, die Realität des taggings weicht jedoch
wie so oft in OSM von den Vorgaben im Wiki ab, was eine Auswertung nicht gerade erleichtert.

Hier ein paar Beispiele wie abweichend von den Wiki Vorgaben getagged wird:
(In dem Startbereich meiner TestApp sieht man schon einige problematische Taggings)

1. Gebäude werden mit amenity=school getagged, einfache und auch mutipolygone, teilweise dann auch mehrere Gebäude, die zur Schule gehören, alle jeweils mit amenity=school
2. die Fläche des Schulgeländes wird getaggt mit amenity=school, zusätzlich aber auch die Gebäude auf dem Gelände ebenfalls mit amenty=school und teilweise auch noch zusätzlich ein Node
3. Es werden Relaltionen verwendet, die mit amenity=school getagged werden, man findet dabei type=site, type=multipolygon und type=collection, auch hier wieder oft noch zusätzlich amenity=school bei den Mitgliedern der Realtionen.

Meine App soll evt. mal helfen, das etwas zu vereinheitlichen.

Dazu sollte aber erst mal etwas detaillierter festgelegt werden, wie das optimale Tagging denn aussehen sollte.

Die Visualisierung ist recht einfach für nodes, Gebäude und Flächen, da openlayers ja das OSM Format kennt, es werden allerdings keine Relationen ausgewertet.
Daher auch mal in die Runde gefragt: hat sich schon mal jemand näher damit beschäftigt, OSM Relationen in Javascript zu visualisieren aus den xml Daten ?

Hier noch ein Bildschirmfoto der App:

Die einzelnen Elemente sind anklickbar und können mit einem Klick auf Bearbeiten auch direkt in JOSM geladen und bearbeitet werden.

Wie im Bild zu erkennen, erkennt man recht leicht die gängigen Fehler, wie hier im Beispiel, wo die Fläche der Schule,
zusätzlich die Gebäude und noch zusätzlich ein Node mit amenity=school getagged sind.

link geht nicht, da gis-1 kein Rechner im Internet ist - zumindest ist der Name unvollständig. gis-1.hkts.de oder sowas wäre nötig

Gruss
walter

Danke, korrigiert.

Was meint Ihr ?

Im Wiki steht nichts über Relationen bei Schulen.

Realtionen sind viel aufwendiger auszuwerten, daher die Frage an diesem Beispiel:

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

Ist da eine Relation wirklich notwendig ? Würde es nicht reichen die Grenze des Schulgeländes mit amenity=school zu taggen ?

Die Grenze ist ja als mit amenity=school getaggt, zusätzlich wurden per site-Relation die einzelnen Bestandteile
zusammengefügt, also mMn. alles in Ordnung.

Site-Relationen decken mMn alle solche Situationen ab: "Was liegt innerhalb eines definierten Bereiches (Fläche) und besteht aus welchen Objekten? "
Da sind Schulen nur eine von vielen.
Aus diesem Grunde halte ich nicht viel davon, ausgerechnet für Schulen die Sache festzuklopfen und alle anderen “Sites” draussen vor zu lassen.

Da allerdings für viele (Mapper und Puter) Relationen immer noch schwer zu greifen sind, schlage ich folgenden Kompromiss vor:
Alles, was sich innerhalb einer amenity-Fläche befindet (amenity=school / amenity=parking / …) gehört dazu.

Gruss
Walter

p.s. ich erfasse derzeit die “Schulen in Hessen” (da war doch mal ein Projekt ???) und halte mich bei den Relationen derzeit auch etwas zurück. Es kann aber sein, dass ich das Thema doch nochmal anfasse und händisch umtagge.

“Knackpunkt” für mich ist eigentlich die Frage, wo die “gemeinsamen/globalen” Tags hinkommen: an die amenity oder in die Relation?
Formal richtiger ist für mich die Relation.

OK, type=site wird also schon verwendet

Wo ist das genau dokumentiert im Wiki ? Denn genau solche Dokumentationen sind notwendig für Auswerter.

Ist site überhaupt ein offizielles tagging ?
Wenn es denn für Schulen (oder andere POIs) verwendet werden kann, sollte das auch im Wiki stehen.

Dazu dann eine Erklärung wo die tags der Schule(name, Adresse und sonstigen Infos) dran sollen bei einer site. Wenn die Tags an der Relation sind, hilft es mir ja zum Beispiel als Auswerter nichts, wenn der perimeter mit amenity=school getagged ist. Ich muss dann trotzdem die Relation auswerten um an die tags zu kommen.

Genau das ist das Problem … wo kommen die Tags hin und wo ist das dokumentiert ?

Was ist mit Schule, die statt type=site type=collection oder type=multipolygon verwenden und die tags an der Relation sind … auch hier muss ich als Auswerter aufwendig und zeitintensiv die Relationen auswerten, was meiner meinung nach unnötig ist, wenn man Relationen bei POIs vermeiden würde.

Ich verstehe ja den Spruch “wir taggen nicht für die Renderer” … das ist auch OK … aber wir sollten so taggen, dass Auswerter auch etwas mit den Daten anfangen können und in diesem Sinne sollte man sich an das KISS Prinzip halten. Relationen auswerten um an simple Sachen wie die Adresse einer Schule zu kommen sind für mich nicht KISS.

Da “site” momentan von fast keiner Anwendung ausgewertet wird, würde ich davor warnen, die Tags nur an
die site zu heften.

also wohin dann ? doppelt an die site und den perimeter ist ja auch nicht gerade überzeugend ?

Ich könnte als Auswerter mit der site leben wenn da ein node verpflichtend wäre, an diesen kommen dann die Tags. Dann gibt es wegen mir die komplizierte site relation, wenn mich aber nur die Infos der Schule interessieren, dann reicht es wenn ich den node auswerte.

Daraus könnte man gut eine allgemeine Regel machen: An die Infos von POIs aller Art sollte man ohne Auswertung von Relationen rankommen. Und pro POI sollte auch die Angabe des POI Typs einmalig sein. Das würde die Auswertung deutlich erleichtern.

Hallo alle,

ich würde eh begrüßen, wenn POI immer ein Punkt wären. Würde das gesamte Handling vereinfachen, siehe das Wheelmap-Problem. So ein Punkt kann auch immer Teil des Way sein. Ich habe auch immer den Verdacht, dass die Attribute eines POI nur deswegen an die Polygone geheftet werden, damit sie auf der Karte korrekt als Zentroid dargestellt werden. Das wiederspricht für mich dem Mantra nicht für Renderer zu mappen. Ein Punkt bleibt für mich ein Punkt und eine POI ist wie der Namen schon sagt erst mal ein Punkt. POI und sie enthaltende Gebäude kann man und sollte sie auch sauber trennen. Trotzdem werde ich deswegen nicht anfangen, fremde Datensätze zu ändern oder Vorgaben zu machen, wie man mappen sollte. Eine Software muss damit klarkommen, wie sie die Daten vorfindet.

LG,

-moenk

Mappen für den Renderer->Gebäude
Mappen für den Router->Eingang
Mappen für niemand->POI in der Luft

Wie ich schon den Hass kriege wenn jemand “Mappen für den Renderer” als Floskel benutzt. Natürlich muss man auch so mappen, dass dann was ordentliches rauskommen kann beim !Rendern!, ansonsten können wir alle POI-Nodes 1 Meter neben die Straße setzen, haben wir nichts gekonnt und sieht am Ende alles wie bei Google aus. Warum zeichnen wir dann überhaupt Gebäude und Flächen ein??? Ich lach jedes Mal wenn ich eine Stadt sehe wo jede Nummer auf den Eingang gesetzt wird, schlechte Platzausnutzung, sieht scheußlich aus und das wichtigste: Es wird keinem Renderer gelingen die Nummer so platzieren, dass es irgendwann gut aussehen wird.

Deshalb: Gebäude/Fläche mit POI und wen es interessiert, soll eine Relation zum Eingang setzen oder diesen als Haupteingang kennzeichnen.

@moenk
Na ja, wann ein Objekt ein POI ist, ist ja in OSM auch nicht genau definiert.
Du würdest dann z.B. Parkplätze auch immer als Node taggen wollen? Und die P-Fläche
mit einem anderen Tag amenity=parking_area oder so? Kann’s auch net sein.

Also nur Node POIs ist sicherlich keine gute Idee.

Natürlich sollte die POis bzw es geht ja eher um die tags der POIs auch an Gebäude oder Flächen

Aber meiner Meinung nach sollten eben 3 Regeln gelten:

1. man sollte an die Infos der POIs ohne Auswertung von Relationen kommen
2. Pro POI nur einmal der typ des POIs, also z.b. nicht Fläche + zusätzlich alle Gebäude mit amenity=school taggen
3. Und auch die Info tags auch nur einmal pro POI, also die Tags nicht an die Fläche und nochmal als zusätzlicher node

http://wiki.openstreetmap.org/wiki/POI

Diesen Verdacht habe ich nicht.
Ein Parkplatz ist eine Fläche und diese Fläche bekommt auch die Tags.

Gruß,
Mondschein

zu 1): sollte man anstreben, aber wenn es nicht anders geht, geht es halt nicht anders. Bspw. weil eine Schule zwei getrennte Schulgelände hat.

zu 2): JA

zu 3): JA, wobei es bei Unterobjekten natürlich auch Infotaggs geben kann. Bspw. die Sporthalle sollte man schon mit der Info versehen, dass es eine Sporthalle ist und was alles sonst noch taggesnwert ist. Aber alle Taggs, die die Schule beschreiben sollen auch an das Objekt mit dem amenity=school.

@moenk: Ich bevorzuge die Darstellung des POI-Symbols einer Fläche an dem Eingang. Je nach Auswerter ist das umgesetzt bzw. möglich umzusetzen.

Dein zu 1) angegebener Fall ist auch der einzige wo meiner Meinung eine Relation Sinn macht … So z.B wenn eine Hochschule noch ein Nebengebäude hat, das einige Blocks entfernt ist. Aber genau für den Fall sollte man sich ein Tagging überlegen, mit dem man das Auswerten der Relationen umgehen könnte, z.B. mit einem node und den entsprechenden Tags als Teil der Relation.

Nur für diese wenigen Ausnahmen, wo eine Relation bei POIs auch fast notwendig ist, eine zeitlich aufwendige Relationen Auswertung durchlaufen zu müssen um auch an diese POIs zu kommen, ist doch unsinnig.

Es lohnt nicht unbedingt da recht viel Aufwand reinzustecken…lieber den Aufwand in API0.7 stecken, sodass wir einen vernünftigen Flächen-Datentyp bekommen.