Einheitliches Tagging für POIs & App zur Kontrolle

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.

misterboo wrote:

http://gis-1/education/img/preview.png

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

wambacher wrote:

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.

misterboo wrote:

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

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.

chris66 wrote:

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.

"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.

wambacher wrote:

chris66 wrote:

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.

"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.

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. 😉

chris66 wrote:

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

moenk wrote:

ich würde eh begrüßen, wenn POI immer ein Punkt wären.

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

moenk wrote:

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.

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

Gruß,
Mondschein

misterboo wrote:

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

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.

aighes wrote:

misterboo wrote:

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

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.

aighes wrote:

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.

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 … yers=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 … yers=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

chris66 wrote:

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. 😉

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

moenk wrote:

Aber soll meinetwegen jeder machen wie er/sie/es will.

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. 😉

moenk wrote:

Ein Parkplatz ist eine Fläche und diese Fläche bekommt auch die Tags.

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

moenk wrote:

chris66 wrote:

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. 😉

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

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 🙂

moenk wrote:

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.

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).

misterboo wrote:

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 🙂

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.

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.

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.

aighes wrote:

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.

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.

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.

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

aighes wrote:

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.

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 🙂

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.

quasilotte wrote:

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

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.

aighes wrote:

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.

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.

misterboo wrote:

...
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 🙂

Und wieder eine Diskussion um Kaisers Bart... 🙄
...wie immer ohne Konsens. 😠
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.

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.

badger123 wrote:

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.

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

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.

badger123 wrote:

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.

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/Rela … posed/Site

Monotar,

monotar wrote:

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".

Auf solche Argumente steh ich ja - das haben wir noch nie so gemacht, das machen wir auch künftig nicht. Ich werd auch nicht damit anfangen, ich mappe auch weiter so, wie ich erkenne das andere das auch machen. Nicht aus einem Mangel aus Induvidualität, sondern einfach um bei den Fluss in diesem schönen Projekt nicht zu stören sondern die Entwicklung voranzubringen.

Fakt ist aber, bei OSM ist die Qualität der Geodaten nach normalen Kriterien ziemlicher Schrott, ohne das hier weiter auszuführen. Sowohl Punkte als auch die "Polygone" sollten vollständig sein. Wir kommen natürlich auch mit solchen "mal so, mal so" Layern klar, und überhaupt ist die OSM trotz der mangelnden Qualität von unbestreitbar hohem praktischen Nutzen.

So eingefahren wie die Entwicklung ist wird ist es auch schwer da noch irgendwas dran zu drehen, allein ein kleiner Lizenzwechsel macht schon einen riesigen Bohei, da sollte lieber alles so weiter laufen, auch wenn das nicht optimal ist. Letztlich gibts da ja auch verschiedene Vorstellungen, was zu verbessern wäre.

LG,

-moenk

misterboo wrote:

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

Nein, das ist ein eindeutiges Negativbeispiel. Selbst wenn man die Relation ignoriert, gibt's da nämlich zwei Schulen - eine als Node und eine ohne weitere Tags als Fläche. Dass das nicht gemacht werden soll, ist doch eigentlich klar?

Man muss also für Kritik an deinem Beispiel nicht mal die Relation heranziehen (wo die Situation wirklich noch nicht ausdiskutiert ist).

badger123 wrote:

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.

Durch Straße geteilt ist nicht mehr "größtmöglich zusammenhängend2, wie ich schrieb. Beide Flächen bekämen bei mir dann unabhängig voneinander amenity=school. Was soll das MP da bringen?

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.

Da reicht doch an jedem Gebäude building=school. Das Problem wäre nur für name=* relevant, damit nicht an jedem Schulgebäude der Name separat klebt.

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

Klasse, wir machen es uns einfach und die Auswertung hat das Problem 🙄

hurdygurdyman wrote:

badger123 wrote:

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.

Durch Straße geteilt ist nicht mehr "größtmöglich zusammenhängend2, wie ich schrieb. Beide Flächen bekämen bei mir dann unabhängig voneinander amenity=school. Was soll das MP da bringen?

Dann hast du zwei Schulen eingetragen. Ob das sinnvoll ist oder der Realität entspricht?

So eine ganz andere Idee...evtl. sollte man mal ein inverses planet-file anbieten. Das mit Relationen beginnt, dann die ways und am Schluss erst die Nodes. Für so Auswertungen wäre das durchaus sinnvoll.

aighes wrote:

...
Dann hast du zwei Schulen eingetragen. Ob das sinnvoll ist oder der Realität entspricht?
...

Nö, ich habe zwei Flächen, die als Schulgelände genutzt werden eingetragen und das entspricht der Realität

Die logische Interpretation einer dummen Maschine ist aber: Hier sind 2 Schulen. amenity=school sagt nämlich genau dies aus. Daher sollte es auch an ein Konstrukt getagt werden, dass die gesamte Schule abbildet.

aighes wrote:

Die logische Interpretation einer dummen Maschine ist aber: Hier sind 2 Schulen. amenity=school sagt nämlich genau dies aus. Daher sollte es auch an ein Konstrukt getagt werden, dass die gesamte Schule abbildet.

Wenn wir Wälder aus Riesen-Polygonen zerschneiden, sind das auch mehrere Flächen aber immer noch ein Wald 🙄
In o.g. Fall sind die Flächen wenigstens durch die Straße getrennt.

hurdygurdyman wrote:

Wenn wir Wälder aus Riesen-Polygonen zerschneiden, sind das auch mehrere Flächen aber immer noch ein Wald 🙄
In o.g. Fall sind die Flächen wenigstens durch die Straße getrennt.

Da liegst du leider leicht daneben: "ein" Wald, erfasst mit zwei landuse - oder auch zwei MP - sind und bleiben in OSM zwei Wälder. Auch wenn diese durch künstliche/mutwillige Überlappung auf der Mapnik-Karte als zusammenhängende Fläche dargestellt werden.
Willst du mehrere unabhängige Flächen zusammenfassen weil sie logisch zusammenhängen aber physikalisch getrennt sind (z.b gleicher Name für verschiedene Teilstücke), kommst du um Relationen nicht rum.
Und das ist auch bei Naturschutzgebieten, Militaria, Industriegebieten, Schulen, Krankenhäusern ... der Fall, wenn sie in mehreren Teilflächen erfasst werden.

Gruss
Walter

wambacher wrote:

hurdygurdyman wrote:

Wenn wir Wälder aus Riesen-Polygonen zerschneiden, sind das auch mehrere Flächen aber immer noch ein Wald 🙄
In o.g. Fall sind die Flächen wenigstens durch die Straße getrennt.

Da liegst du leider leicht daneben: "ein" Wald, erfasst mit zwei landuse - oder auch zwei MP - sind und bleiben in OSM zwei Wälder. Auch wenn diese durch künstliche/mutwillige Überlappung auf der Mapnik-Karte als zusammenhängende Fläche dargestellt werden.
Willst du mehrere unabhängige Flächen zusammenfassen weil sie logisch zusammenhängen aber physikalisch getrennt sind (z.b gleicher Name für verschiedene Teilstücke), kommst du um Relationen nicht rum.
Und das ist auch bei Naturschutzgebieten, Militaria, Industriegebieten, Schulen, Krankenhäusern ... der Fall, wenn sie in mehreren Teilflächen erfasst werden.

Gruss
Walter

Zur Klarstellung: ich meinte einen Wald in der Realität. Ansonsten gebe ich dir recht, aber wird das auch so gemacht?

hurdygurdyman wrote:

wambacher wrote:

hurdygurdyman wrote:

Wenn wir Wälder aus Riesen-Polygonen zerschneiden, sind das auch mehrere Flächen aber immer noch ein Wald 🙄
In o.g. Fall sind die Flächen wenigstens durch die Straße getrennt.

Da liegst du leider leicht daneben: "ein" Wald, erfasst mit zwei landuse - oder auch zwei MP - sind und bleiben in OSM zwei Wälder. Auch wenn diese durch künstliche/mutwillige Überlappung auf der Mapnik-Karte als zusammenhängende Fläche dargestellt werden.
Willst du mehrere unabhängige Flächen zusammenfassen weil sie logisch zusammenhängen aber physikalisch getrennt sind (z.b gleicher Name für verschiedene Teilstücke), kommst du um Relationen nicht rum.
Und das ist auch bei Naturschutzgebieten, Militaria, Industriegebieten, Schulen, Krankenhäusern ... der Fall, wenn sie in mehreren Teilflächen erfasst werden.

Gruss
Walter

Zur Klarstellung: ich meinte einen Wald in der Realität. Ansonsten gebe ich dir recht, aber wird das auch so gemacht?

Auch in der Realität kommt sowas vor (ich glaub das war der Harz) - das EIN Wald in meheren Teilen erstellt ist und durch eine Realtion zusammengefasst ist!
Dort ist es sogar noch extremer da nicht Flächen zu einem Wald zusammengefsst sind sondern der Wald erst durch zusammensetzten von Ways zu einer Fläche wird (Grund ist dort die 2000 Punktegrenze von Ways).

Einheitliches Tagging wird ohne feste vorgeschriebene Regeln nicht gehen und diese werden in OSM nicht gewollt - deshalb alles für des Kaisers Bart!!!!

hurdygurdyman wrote:

wambacher wrote:

hurdygurdyman wrote:

Wenn wir Wälder aus Riesen-Polygonen zerschneiden, sind das auch mehrere Flächen aber immer noch ein Wald 🙄
In o.g. Fall sind die Flächen wenigstens durch die Straße getrennt.

Da liegst du leider leicht daneben: "ein" Wald, erfasst mit zwei landuse - oder auch zwei MP - sind und bleiben in OSM zwei Wälder. Auch wenn diese durch künstliche/mutwillige Überlappung auf der Mapnik-Karte als zusammenhängende Fläche dargestellt werden.
Willst du mehrere unabhängige Flächen zusammenfassen weil sie logisch zusammenhängen aber physikalisch getrennt sind (z.b gleicher Name für verschiedene Teilstücke), kommst du um Relationen nicht rum.
Und das ist auch bei Naturschutzgebieten, Militaria, Industriegebieten, Schulen, Krankenhäusern ... der Fall, wenn sie in mehreren Teilflächen erfasst werden.

Gruss
Walter

Zur Klarstellung: ich meinte einen Wald in der Realität. Ansonsten gebe ich dir recht, aber wird das auch so gemacht?

Auch in der Realität kommt sowas vor (ich glaub das war der Harz) - das EIN Wald in meheren Teilen erstellt ist und durch eine Realtion zusammengefasst ist!
Dort ist es sogar noch extremer da nicht Flächen zu einem Wald zusammengefsst sind sondern der Wald erst durch zusammensetzten von Ways zu einer Fläche wird (Grund ist dort die 2000 Punktegrenze von Ways).

Einheitliches Tagging wird ohne feste vorgeschriebene Regeln nicht gehen und diese werden in OSM nicht gewollt - deshalb alles für des Kaisers Bart!!!!

quasilotte wrote:

Einheitliches Tagging wird ohne feste vorgeschriebene Regeln nicht gehen und diese werden in OSM nicht gewollt - deshalb alles für des Kaisers Bart!!!!

Da ich es genauso sehe könnte man das Problem mit dem komplizierten Auswerten vielleicht auch anders Lösen.

Und zwar würde ich hierfür die Idee von Frederik (woodpeck) aufgreifen.
http://forum.openstreetmap.org/viewtopi … 08#p219608

Dort wird einfach eine zusätzliche Datenbank verwendet die für POIs Relationen, Wege und Punkte auswertet und nur als Punkt wieder zur Verfügung stellt. Wenn eine solche Datenbank zentral zur Verfügung steht könnten Auswerter einfach auf die POIs zurückgreifen. Die Daten selber würden aber weiterhin als Relationen, Wege und Punkte in der eigentlichen OSM-Datenbank zur Verfügung stehen.
Ansonsten führt jeder Auswerter diesen Ansatz mehr oder weniger bei sich selber durch. Sei es in einer Datenbank oder nur in einer Liste.

Das ganze funktioniert dann genau wie mit den Karten-Server. Ein Auswerter kann entweder auf die Daten zurückgreifen, bei speziellen Wünschen aber auch die Daten selbständig aufbereiten.

quasilotte wrote:

...
Auch in der Realität kommt sowas vor (ich glaub das war der Harz) - das EIN Wald in meheren Teilen erstellt ist und durch eine Realtion zusammengefasst ist!
Dort ist es sogar noch extremer da nicht Flächen zu einem Wald zusammengefasst sind sondern der Wald erst durch zusammensetzten von Ways zu einer Fläche wird (Grund ist dort die 2000 Punktegrenze von Ways).

Einheitliches Tagging wird ohne feste vorgeschriebene Regeln nicht gehen und diese werden in OSM nicht gewollt - deshalb alles für des Kaisers Bart!!!!

Mittlerweile sind wir leider vollkommen OT und wieder in einer dieser MP-Diskussionen.
Zusätzlich wird das ganze auch noch durch unterschiedliche Interpretation von Begriffen befeuert. Für mich ist der Harz (oder Schwarzwald usw.) kein Wald im Sinne der Erfassung in OSM mit landuse=forest, weshalnb das Beispiel für mich hinkt.

Zum zweiten Absatz "Einheitliches tagging..." stimme ich dir voll zu.
Leider erinnere ich mich an keinen thread hier, der bei solchen Diskussionen nicht irgendwann ergebnislos im Sande verlief. 🙄

quasilotte wrote:

Einheitliches Tagging wird ohne feste vorgeschriebene Regeln nicht gehen und diese werden in OSM nicht gewollt - deshalb alles für des Kaisers Bart!!!!

+1

Viele Betonköpfe. 😉

Wie sieht eigentlich das optimale Tagging für Flächen POIs aus ? Am Beispiel einer Schule ?

Wo sollten die Adress Tags hin ? Gibt es da ne Wiki Seite mit Hinweisen ?

Beim Analysieren konnte ich wenig einheitliches finden.

Tags an der Fläche, Tags an einem Gebäude, Tags an mehreren Gebäuden, Tags am Eingang eines Gebäudes, Tags an einem Node, und auch viele wo die Tags gleich an der Fläche, am Gebäude, und an einem Node 3-fach vorhanden sind.

Wie sollte das im Optimalfall aussehen ?

http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool
ich lese hier s:
Alle Infos, Namen, Adresse usw an die amenity=school die das kompl. gebiet abgrenzt.
Innerhalb der Fläche dann einzelne gebäude nur mit bulding=yes/school, leisure=pitch usw.

MoTaBi wrote:

http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool
ich lese hier s:
Alle Infos, Namen, Adresse usw an die amenity=school die das kompl. gebiet abgrenzt.
Innerhalb der Fläche dann einzelne gebäude nur mit bulding=yes/school, leisure=pitch usw.

Nur mal ein Beispiel:

http://osm.misterboo.de/education/?zoom … yers=B00TT

In Cottbus sind keine Adressen an der Fläche, sondern am Gebäude

Sehr nett für Auswerter, denn die müssen, um an die Adressen zu kommen, noch räumliche Abragen machen:

Ist auf dem Gelände mit amenity=school evt. ein Gebäude mit der Adresse ? oder noch ein Node ? oder beides ? oder mehrere Gebäude mit mehreren Adressen ? Kann ich am Tagging sehen dass die Adresse auch tatsächlich die Adresse der Schule ist ?

Schön wird es dann zu entscheiden, welche Adresse denn die richtige für die Schule ist, im Falle wenn da noch das Hausmeisterhaus auf dem Gelände ist oder mehrere Gebäude mit unterschiedlichen Adressen sind.

moment mal, du bist länger dabei als ich 😉

bei komplexeren/größeren Anlagen sind die (unterschiedlichen) Adressen am Gebäude sicherlich sinnvoll.
Auch wenn sich die Bezeichnung der Gebäude unterscheidet sind names angebracht zB "Bau 3", aber eben nicht "Schule xy" als name an 5 benachbarte Gebäude pappen.

irgendwas doppelt einzutragen versuch ich zu vermeiden. Entweder, oder.
Ergänz ich die area, kommt der node in den Müll. 😄

MoTaBi wrote:

moment mal, du bist länger dabei als ich 😉

bei komplexeren/größeren Anlagen sind die (unterschiedlichen) Adressen am Gebäude sicherlich sinnvoll.
Auch wenn sich die Bezeichnung der Gebäude unterscheidet sind names angebracht zB "Bau 3", aber eben nicht "Schule xy" als name an 5 benachbarte Gebäude pappen.

irgendwas doppelt einzutragen versuch ich zu vermeiden. Entweder, oder.
Ergänz ich die area, kommt der node in den Müll. 😄

Ab wann ist eine Anlage komplex ? Wie soll getagged werden dass man bei größeren Anlagen, wo die Adresse nicht am Gelände ist sondern an einem Gebäude, so dass man erkennen kann dass das auch die ofizielle Adresse der Schule ist ? Wo ist das beschrieben ?

Ein Anfänger und ein Auswerter hält sich erst mal an das Wiki:

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

Dort steht ja nicht mal wohin die Tags gehören ... im Grunde steht da nur was von dem Schulgelände. Jeder macht dann daraus mehr oder weniger was er will. Und so sieht dann auch das Tagging in der Realtiät aus. Jeder setzt die Tags hin wo er will.

Ganz zu schweigen von der unnötigen Zeit und Rechenpower die man braucht um räumliche Abfragen machen zu müssen um an die Adresse einer Schule zu kommen.

Problem erkannt. 🤔

Ich möchte nochmal gerne nachhaken, da ich das gerne in meiner App konkret als Leitfaden angeben möchte:

Wohin sollen bei Flächen POIs die Tags besonders die Adress Tags ?

Ich kann leider kein einheitliches System feststellen momentan in den OSM Daten.

Problem bei den Tags an der Fläche: das ist bei großen Flächen recht ungenau, außerdem können ja durchaus mehrere Gebäude mit einer Adresse auf dem Schulgelände sein.

Bei den Tags an den Gebäuden wäre dann eine erst eine aufwändige Auswertung notwendig und es es müsste dann eine Richtline geben, wie zu taggen ist, um herauszufinden, dass die Adresse eines Gebäudes auch die Adresse der Schule ist.

Hier zwei Beispiele:

http://osm.misterboo.de/education/?zoom … yers=B00TT

An der linken Schule sind die Tags am Gebäude ... an der rechten an der Fläche, dabei sind Fläche und Gebäude mit amenity=school getagged

misterboo wrote:

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.

Genau diese Relation ist überflüssig, da die Fläche als amenity=school getaggt ist. So stehts übrigens auch im Proposal der site. Wenn site, muß das amenity an der Fläche weg.

Radeln wrote:

misterboo wrote:

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.

Genau diese Relation ist überflüssig, da die Fläche als amenity=school getaggt ist. So stehts übrigens auch im Proposal der site. Wenn site, muß das amenity an der Fläche weg.

In der Theorie 🙂 In der Praxis wird man wohl eher gelyncht wenn man das korrigieren würde und die tags von der Fläche entfernen würde, weil site eben nicht mal offiziell ist und wohl in keiner Anwendung bisher ausgewertet wird und somit auch nicht von mapnik in der Karte angezeigt wird.

Und auch wenn ich mich da schon wieder mal wiederhole: Wir brauchen einfache verständliche Regeln, die auch gut irgendwo dokumentiert sind. Das hilft Mappern und Auswertern, die sich daran halten können. Und dabei sind die POIs doch eigentlich noch was einfaches, wenn man sich die Diskussionen über Spurmapping oder ÖPNV ansieht.

misterboo wrote:

Radeln wrote:

misterboo wrote:

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.

Genau diese Relation ist überflüssig, da die Fläche als amenity=school getaggt ist. So stehts übrigens auch im Proposal der site. Wenn site, muß das amenity an der Fläche weg.

In der Theorie 🙂 In der Praxis wird man wohl eher gelyncht wenn man das korrigieren würde und die tags von der Fläche entfernen würde, weil site eben nicht mal offiziell ist und wohl in keiner Anwendung bisher ausgewertet wird und somit auch nicht von mapnik in der Karte angezeigt wird.

Und auch wenn ich mich da schon wieder mal wiederhole: Wir brauchen einfache verständliche Regeln, die auch gut irgendwo dokumentiert sind. Das hilft Mappern und Auswertern, die sich daran halten können. Und dabei sind die POIs doch eigentlich noch was einfaches, wenn man sich die Diskussionen über Spurmapping oder ÖPNV ansieht.

Für Regeln bin ich von Anfang an und deswegen auchschon angeeckt.
Daß die Tags an der Fläche bei Anwenden der site unnötig sind, dürfte wohl klar sein. Ich hatte aber auch eindeutig geschrieben, daß die site in diesem einfachen Fall total überflüssig ist. BTW, JOSM bietet sogar eine Vorlage dafür und wir mappen nicht für Renderer, oder doch?
Ergo. Die site weg, Tags , die das ganze Gelände betreffen, an die Fläche, den POI weg.
Dreimal amenity=school ist Quark. Wie wärs denn, die Gebäude ebenfalls damit zu taggen. 😉 Findet/fand man auch.

Radeln wrote:

Wie wärs denn, die Gebäude ebenfalls damit zu taggen. 😉 Findet/fand man auch.

Das ist leider momentan sehr oft zu finden: amenty=school 2-fach, 3-fach oder noch mehr fach 🙂

z.B auch in meinem o.g. Beispiel:

http://osm.misterboo.de/education/?zoom … yers=B00TT

an der Fläche und an den Gebäuden ...

hier auch ein Beipiel für mehr-fach (Fläche, mehrere Gebäude und Node)

http://osm.misterboo.de/education/?zoom … yers=B00TT

misterboo wrote:

Radeln wrote:

Wie wärs denn, die Gebäude ebenfalls damit zu taggen. 😉 Findet/fand man auch.

Das ist leider momentan sehr oft zu finden: amenty=school 2-fach, 3-fach oder noch mehr fach 🙂

z.B auch in meinem o.g. Beispiel:

http://osm.misterboo.de/education/?zoom … yers=B00TT

an der Fläche und an den Gebäuden ...

hier auch ein Beipiel für mehr-fach (Fläche, mehrere Gebäude und Node)

http://osm.misterboo.de/education/?zoom … yers=B00TT

Dann weg damit. Das area=yes ist IMHO ebenfalls überflüssig.

Zusatzfrage an Dich (etwas off topic): Kennst Du den Wendelinus-Radweg? Sieht in Bing größtenteils aus, als wäre es eine ehemalige Bahnstrecke IMHO auch nicht richtig getaggt, vom gleichen Mapper wie die Schulen.

Habe ihn angeschrieben:

der Radweg http://www.openstreetmap.org/browse/relation/180492 ist größtenteils mit 'highway=service' getaggt. Wenn dies ein reiner Rad-/Fußweg ist, ist dies nicht geeignet, IMHO sogar falsch. Besser wäre highway=cycleway + surface + foot=yes. Dann braucht es kein access=no, kein horse=no, bicyle=yes wäre dann auch unnötig. Das teilweise vorhandene tracktype ist eh verkehrt.

Stehen da blaue Schilder für Rad-/Fußweg, dann müßte bicycle/foot=designated hin.

Bin gespannt ob er antwortet.

Radeln wrote:

misterboo wrote:

Radeln wrote:

Wie wärs denn, die Gebäude ebenfalls damit zu taggen. 😉 Findet/fand man auch.

Das ist leider momentan sehr oft zu finden: amenty=school 2-fach, 3-fach oder noch mehr fach 🙂

z.B auch in meinem o.g. Beispiel:

http://osm.misterboo.de/education/?zoom … yers=B00TT

an der Fläche und an den Gebäuden ...

hier auch ein Beipiel für mehr-fach (Fläche, mehrere Gebäude und Node)

http://osm.misterboo.de/education/?zoom … yers=B00TT

Dann weg damit. Das area=yes ist IMHO ebenfalls überflüssig.

Zusatzfrage an Dich (etwas off topic): Kennst Du den Wendelinus-Radweg? Sieht in Bing größtenteils aus, als wäre es eine ehemalige Bahnstrecke IMHO auch nicht richtig getaggt, vom gleichen Mapper wie die Schulen.

Habe ihn angeschrieben:

der Radweg http://www.openstreetmap.org/browse/relation/180492 ist größtenteils mit 'highway=service' getaggt. Wenn dies ein reiner Rad-/Fußweg ist, ist dies nicht geeignet, IMHO sogar falsch. Besser wäre highway=cycleway + surface + foot=yes. Dann braucht es kein access=no, kein horse=no, bicyle=yes wäre dann auch unnötig. Das teilweise vorhandene tracktype ist eh verkehrt.

Stehen da blaue Schilder für Rad-/Fußweg, dann müßte bicycle/foot=designated hin.

Bin gespannt ob er antwortet.

Schießt du beim Wendelinus-Radweg nicht ein bischen über Ziel hinaus?

Nur weil das ein Radweg im Namen trägt und auf einer ehmaligen Bahnstrecke ist gleich auf einen Radweg zu schließen?

Die meisten Namens-Radwege führen auf Nichtradwegen (also ohne die Blauen Schilder) - die meisten haben das Schild mit Roten Kreis + Anlieger bzw. Fort u. Landwirtschaft frei ...

Sowas kannst du nur vor Ort überprüfen und für Gemeinden ist es viel einfacher ein paar Hinweisschilder aufzustellen als öffiziell einen Radweg durchzubringen.

quasilotte wrote:

Radeln wrote:

misterboo wrote:

Das ist leider momentan sehr oft zu finden: amenty=school 2-fach, 3-fach oder noch mehr fach 🙂

z.B auch in meinem o.g. Beispiel:

http://osm.misterboo.de/education/?zoom … yers=B00TT

an der Fläche und an den Gebäuden ...

hier auch ein Beipiel für mehr-fach (Fläche, mehrere Gebäude und Node)

http://osm.misterboo.de/education/?zoom … yers=B00TT

Dann weg damit. Das area=yes ist IMHO ebenfalls überflüssig.

Zusatzfrage an Dich (etwas off topic): Kennst Du den Wendelinus-Radweg? Sieht in Bing größtenteils aus, als wäre es eine ehemalige Bahnstrecke IMHO auch nicht richtig getaggt, vom gleichen Mapper wie die Schulen.

Habe ihn angeschrieben:

der Radweg http://www.openstreetmap.org/browse/relation/180492 ist größtenteils mit 'highway=service' getaggt. Wenn dies ein reiner Rad-/Fußweg ist, ist dies nicht geeignet, IMHO sogar falsch. Besser wäre highway=cycleway + surface + foot=yes. Dann braucht es kein access=no, kein horse=no, bicyle=yes wäre dann auch unnötig. Das teilweise vorhandene tracktype ist eh verkehrt.

Stehen da blaue Schilder für Rad-/Fußweg, dann müßte bicycle/foot=designated hin.

Bin gespannt ob er antwortet.

Schießt du beim Wendelinus-Radweg nicht ein bischen über Ziel hinaus?

Nur weil das ein Radweg im Namen trägt und auf einer ehmaligen Bahnstrecke ist gleich auf einen Radweg zu schließen?

Die meisten Namens-Radwege führen auf Nichtradwegen (also ohne die Blauen Schilder) - die meisten haben das Schild mit Roten Kreis + Anlieger bzw. Fort u. Landwirtschaft frei ...

Sowas kannst du nur vor Ort überprüfen und für Gemeinden ist es viel einfacher ein paar Hinweisschilder aufzustellen als öffiziell einen Radweg durchzubringen.

Kennst Du den Radweg?
Wenn nein, frage ich mich, was das rumgemeckere soll? Schließlich habe ich keine Tatsachen geschaffen.
Egal, wie es ist, highway=service dürfte fraglich sein.

Radeln wrote:

quasilotte wrote:

Schießt du beim Wendelinus-Radweg nicht ein bischen über Ziel hinaus?

Nur weil das ein Radweg im Namen trägt und auf einer ehmaligen Bahnstrecke ist gleich auf einen Radweg zu schließen?

Die meisten Namens-Radwege führen auf Nichtradwegen (also ohne die Blauen Schilder) - die meisten haben das Schild mit Roten Kreis + Anlieger bzw. Fort u. Landwirtschaft frei ...

Sowas kannst du nur vor Ort überprüfen und für Gemeinden ist es viel einfacher ein paar Hinweisschilder aufzustellen als öffiziell einen Radweg durchzubringen.

Kennst Du den Radweg?
Wenn nein, frage ich mich, was das rumgemeckere soll? Schließlich habe ich keine Tatsachen geschaffen.
Egal, wie es ist, highway=service dürfte fraglich sein.

Das ist kein Rumgemeckere sondern eine Feststellung!

Wie die highway Tags gesetzt sind gibts nichts zu meckern und auch service ist passend gesetzt.
Die Relation ist eine Route und nicht ein cycleway-Relation, das ist in den Ways richtig getaggt!
Einzig das er an die ganzen cycleway noch den namen drangepappt hat ist überflüssig - der reicht einmal in der Route-Relation, an den Ways braucht der nicht nochmal zu hängen!

Man sollte alle Ways anschauen und nicht nur die ersten 2 und sagen da fehlt cycleway !!!

quasilotte wrote:

Radeln wrote:

quasilotte wrote:

Schießt du beim Wendelinus-Radweg nicht ein bischen über Ziel hinaus?

Nur weil das ein Radweg im Namen trägt und auf einer ehmaligen Bahnstrecke ist gleich auf einen Radweg zu schließen?

Die meisten Namens-Radwege führen auf Nichtradwegen (also ohne die Blauen Schilder) - die meisten haben das Schild mit Roten Kreis + Anlieger bzw. Fort u. Landwirtschaft frei ...

Sowas kannst du nur vor Ort überprüfen und für Gemeinden ist es viel einfacher ein paar Hinweisschilder aufzustellen als öffiziell einen Radweg durchzubringen.

Kennst Du den Radweg?
Wenn nein, frage ich mich, was das rumgemeckere soll? Schließlich habe ich keine Tatsachen geschaffen.
Egal, wie es ist, highway=service dürfte fraglich sein.

Das ist kein Rumgemeckere sondern eine Feststellung!

Wie die highway Tags gesetzt sind gibts nichts zu meckern und auch service ist passend gesetzt.
Die Relation ist eine Route und nicht ein cycleway-Relation, das ist in den Ways richtig getaggt!
Einzig das er an die ganzen cycleway noch den namen drangepappt hat ist überflüssig - der reicht einmal in der Route-Relation, an den Ways braucht der nicht nochmal zu hängen!

Man sollte alle Ways anschauen und nicht nur die ersten 2 und sagen da fehlt cycleway !!!

DIe Änderung in cycleway ist am 30.04. erfolgt, Stunden nachdem ich den Mapper angeschrieben habe. Ergo haben etwas aneinander vorbei gewettert. 😉 Daß er so schnell reagiert, hatte ich nicht erwartet.

wambacher wrote:

misterboo wrote:

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

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.

Wenn die zur Schule gehörenden Teile innerhalb einer Fläche liegen (amenity=school) ist eine Site nicht erforderlich. Siehe site-Proposal.

Jemand wollte bei meiner kleinen Themenkarte auch die Relationen im Bereich education angezeigt bekommen. Da er keine Email hinterlassen hat, evt. liest er ja hier mit. Jetzt werden auch die Realtionen angezeigt.

z.B. Uni Augsburg

http://osm.misterboo.de/education/?zoom … ers=B00TTT

Radeln wrote:

wambacher wrote:

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.

Wenn die zur Schule gehörenden Teile innerhalb einer Fläche liegen (amenity=school) ist eine Site nicht erforderlich. Siehe site-Proposal.

Das sehe ich inzwischen (*) auch so. wenn alle Objekte in einem räumlichen Kontex stehen - also alle innerhalb einer Area sind, bringt eine site-Relation fast nix.
Einerseits hat es der Renderer etwas einfacher, da er nicht suchen muss, andererseits müssen ALLE Mapper aufpassen, da nichts falsch zu machen.
Und da sind mir die Mapper näher 😉
Sites sind z.B. prima für Bushaltestellen, da die alle irgendwie zusammen gehören aber doch über eine undefinierte Fläche verstreut sind.

Gruss
walter

• ) „Man kann immer seinen Standpunkt ändern, weil dir niemand verbieten kann, klüger zu werden.“
  

oder etwas direkter: „Was interessiert mich mein Geschwätz von gestern.“
Konrad Adenauer

Hallo,

wie würdet ihr denn in diesem Fall konkret "richtig" taggen:

http://www.openstreetmap.org/?lat=51.91 … 8&layers=M

Das ganze Gelände ist als Schule markiert und mit Schulzentrum beschriftet.
Da drauf steht ein großes Schulgebäude in dem drei Schultypen (als Node) untergebracht sind.
Also gibt es jetzt viermal amenity=school.
Man könnte dies bei der Fläche weglassen, aber dann fällt die als Information weg, was auch blöd ist.

(Ich weiß, Adressen könnte man an die Fläche verschieben, aber darum geht es mir gerade nicht)

Noch zwei allgemeine Anmerkungen von mir als Anfänger:
- Für so ein Konstrukt würde ich keine Relation angeben, da ja alles innerhalb der Fläche liegt.
Bei Straßen schreibt man ja auch nicht dazu in welcher Stadt die liegen.
- Es mag ein Vorteil von OSM sein, dass es flexibel ist und jeder machen kann was er will,
aber als Einsteiger wünscht man sich doch klare Regeln damit man sicher sein kann,
dass die eigenen Daten auch genutzt werden.
Ausnahmefälle kommen dann früher oder später sowieso dazu.

Grüße
Daniel

wambacher wrote:

Sites sind z.B. prima für Bushaltestellen, da die alle irgendwie zusammen gehören aber doch über eine undefinierte Fläche verstreut sind.

Hallo Walter

Für das Zusammenfassen von Haltestellen gibt es eine eigene Relation.
Nach Public_Transport#Stop_area sind type=public_transport plus public_transport=stop_area für die Relation zu verwenden.

Edbert (EvanE)