Wie mit "falsch" getaggten POIs umgehen?

Moin,

ich bin gerade über Folgendes gestolpert und würde gerne wissen, wie man am besten damit umgeht.

Das Wiki (https://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant) sagt, dass nur nodes und areas mit amenity=restaurant getaggt werden sollen, was ja auch Sinn ergibt. Gleichzeitig zeigt TagInfo, dass es Stand eben 1.222 relations gibt, die entsprechend getaggt sind.

Sehe ich mir mal eine beliebige (https://www.openstreetmap.org/relation/9822265) davon an, sehe ich hier 3 ways, die eigentlich eine area ergeben würden.

Nach meinem Verständnis sollte man nun die 3 ways zu einer area vereinen und die Tags der relation auf die area übertragen.

Jetzt meine Fragen:

  • Ist das so richtig?
  • Wenn ja, gibt es ein Tool, das solche Aufgaben besonders einfach macht? Mit ID ist das wohl ziemlich mühsam.
  • Sollen “falsch”-getaggte POIs von Apps unterstützt werden?

Danke und LG, Georg

Es gibt zwei Arten, Flächen darzustellen. Einmal als geschlossener, ringförmiger Way, aber auch als Relation vom Typ multipolygon.
Der Hinweis “may be used on areas” im Wiki bezieht sich auf beides.

Dein Beispiel ist also völlig in Ordnung.

OK, ich verstehe jetzt, dass Flächen auch über relations dargestellt werden können, auch wenn das wahrscheinlich nicht optimal ist.

Das Wiki sagt aber in meinem Beispiel auch, amenity=restaurant “should not be used on relations”. Was bedeutet das dann in diesem Fall? Denn hier widerspricht das Beispiel dem Wiki.

Genauso ist das für mich - und nicht vergessen, die Relation dann zu wischen.

Nur frage ich mich, wie du eine “Area” definiert hast - für mich umfaßt OSM nur nodes, ways, und relations. Zwar gibt es ways mit “area=yes”, aber war dieser Tag nicht altmodisch/deprecated?

M.fr.Gr.,

Fein, ich lerne weiter :slight_smile: Auf die area komme ich aus der zitierten Wiki-Seite, die sagt “may be used on areas” und “should not be used on ways”. Nach meinem Verständnis ist eine area kein eigenes OSM element sonder ein way, bei dem Anfangs- und Endpunkt identisch sind. Die area wird also als way gespeichert, aber man nennt sie auf Grund der Flächeneigenschaft eben area. Vielleicht hab ich das aber auch falsch verstanden? Wo steht denn das mit deprecated?

Hab gerade noch ein Beispiel gefunden, wo der Tag wahrscheinlich sogar auf einer Relation sein muss: https://www.openstreetmap.org/relation/8493511. Wie interpretiere ich dann hier das Wiki? Lieber eine eigene Node mit den Tags setzen und die Gebäude als Ways? Oder doch die Relation taggen?

An “area=yes” ist nichts deprecated. Er wird aber nur in Fällen gebraucht, wo zwischen einem Rundweg und einer Fläche unterschieden werden muss. Ein amenity=restaurant ist nie ein Weg, deswegen wird es immer als area betrachtet. Eine barrier=fence hingegen kann nie eine Fläche sein, wird also immer als geschlossener Weg betrachtet. Nur in Fällen wie z.B. highway=service ist die Sache nicht eindeutig und das Tag wird gebraucht.
Das ist aber eigentlich alles im Wiki beschrieben:
https://wiki.openstreetmap.org/wiki/Area

Das ist eine Relation vom Typ Multipolygon, also ein “Area”. Alles korrekt gemappt (wenn das Restaurant so wie eingetragen aus exakt diesen beiden Gebäuden besteht) und entsprechend der Definition im Wiki.

Danke - da habe ich auch was hinzugelernt :slight_smile: !

Das hilft Dir zwar beim eigentlichen Problem nicht viel weiter, aber restaurant+building ist nur in recht wenigen Fällen richtig (hier allerdings wohl doch).
Zusätzlich ist die Relation in diesem Beispiel auch nicht nötig, wozu?
Niedliches Partyzelt, das muss unbedingt in eine Restaurant-relation[1] … kann man machen, man kanns aber auch lassen und gleich 'nen Node in die Mitte tun.
Wenn man da eine Relation baut, dann ist diese hier ziemlich inkonsequent, da Terrasse/ Garten ja auch dazugehören.

[1]https://c.tfstatic.com/w_656,h_368,c_fill,g_auto:subject,q_auto,f_auto/restaurant_photos/089/204089/source/casa-das-palmeiras-entrada-5f888.jpg

Widerspricht wie auch meine andere Antwort auf Deine Antwort, dem Wiki, das sagt, dass keine Relations mit amenity=restaurant getaggt werden sollen… In meinen Augen also nicht korrekt gemappt bzw. vielleicht korrekt gemappt aber nicht korrekt getaggt?

Flächen können aus einem einzigen geschlossenen way erstellt werden, oder als Relation aus mehreren zusammengesetzten Einzellinien. Diese Einzellinien wiederum sind Teil einer anderen, weiteren flächenbeschreibenden Relation. Das ist hier der Fall. Grundsätzlich ist diese Erfassungsweise nicht falsch und zulässig. In meinen Augen ist das aber eine unnötige Verkomplizierung des Datenbestandes. Ich selbst bin kein Freund davon und bewerte das als grundsätzlich fehleranfällig. Gerade und vor allem wenn ganze Landstriche auf diese Weise erfasst sind, macht man es Neulingen äußerst schwer. Da sich viele an sowas nicht herantrauen, finden meinem Eindruck nach dort eher weniger Aktualisierungen statt… Solche Relationen aus mehreren zusammengesetzten outer-Rollen sollten meiner Meinung nach nur eingesetzt werden, wenn die datentechnische Anzahl an nodes (2000 Stützpunkte) erreicht wird, ansonsten nicht.

Das vorliegenden Beispiel würde ich persönlich auflösen.

Sven

Edit: Stützpunkteanzahl hinzugefügt.

Völlig zugestimmt, Sven. Manchmal ärgert auch mich die Verwendung von Relations wenn es dafür kein Bedarf oder Notwendigkeit gibt. Es gibt Leute die Ihre Intelligenz anwenden om die Dings unkompliziert zu machen - und es gibt leider auch andere…

“relations” im Wiki ist ein bisschen unklar, weil es eben nicht alle Relationen meint sondern nur manche, und nicht genau definiert ist, welche. Multipolygonrelationen meint es jedenfalls nicht. Auch Relationen die man neu erfindet meint es nicht.

Ah, das würde einiges erklären! Ist das irgendwo dokumentiert?

“onRelation: yes if the feature being described is suitable for use on (non-multipolygon) relation elements, no otherwise”
von Template:ValueDescription#Feature_usage

Im Prinzip bedeuten die Icons im Wiki das, was man erwarten würde – nur dass Flächen als eigener Datentyp behandelt werden und nicht als Ways bzw. Relationen zählen, auch wenn sie das technisch gesehen (noch) sind.