POI nicht als Polygon eintragen!

Moin,

ich stoße hiermit mal eine Diskussion an, die es in ähnlicher Form sicher schon öfter gegeben hat und hol mir einen Satz heiße Ohren hier ab. Aber ich sehe hier Diskussionsbedarf!

Schon seit langem sehe ich POI als Polygon eingetragen. Das kann man natürlich tun. Ein Gebäude, das ALDI gehört kann man als ALDI mappen mit seinem Polygon. Und weil man das kann wird das auch gemacht. Erscheint zunächst einmal auch als logisch.

Ich halte das schon seit fast genau so lange eigentlich für falsch. Das führt nun nicht dazu, dass ich das ändern würde, wenn ich es sehe. Aber ich finde es nicht richtig und wird der Natur eines POI (der “Punkt” ist hier schon Teil des Namens) auch nicht gerecht. Der POI wird impliziert als Zentroid eines Polygons gemappt. Das ist unnötig kompliziert.

Es macht den Umgang mit den Geodaten für jemand der sich für POI interessiert komplizierter als erforderlich. Wir sollten ein Interesse daran haben, dass der Umgang mit den Geodaten einfach ist. Das wird dann auch zu mehr schönen Apps und Webseiten führen, die unsere Daten nutzen, weil es einfacher ist.

Der POI als Punkt gibt auch die Möglichkeit, auf den Eingang zu zeigen. Er kann auch Teil des Polygons (oder hier eigentlich Way, aber lassen wir das) sein. Mit dem Polygon mappen wir eigentlich für die Karte, damit der Renderer die Beschriftung schön mitten rein setzt, und das wollen wir ja nicht.

Es gibt sicher Fälle, da sollte man die Fläche mappen, z.B. für einen Parkplatz, das sind aber Ausnahmen, die nicht als Rechtfertigung herhalten sollten, warum man das auch bei Restaurants, Supermärkten, Bar, Cafes und ähnlichem machen muss.

Ganz übel wirds, wenn die Attribute eines Polygons in einer Relation hängen. Wollen wir jedem, der was mit POI und OSM machen will die Hausaufgabe geben, Ways und Relationen auch noch auszuwerten? Es sollte unser Ziel sein, die Geodaten so bereitzuhalten, dass man sie einfach nutzen kann und nicht zu zeigen wie genial wir sind.

Darum erfasse ich POI nur als Punkte. Und nun seid Ihr dran :wink:

LG,

-moenk

Das darfst Du. Jeder so wie er mag.

Es gibt sicher auch Argumente für Flächen-POIs.

Ein Aldi ist nunmal kein Punkt sondern ein flächenhaftes Etwas. :wink:

Wenn die Eigenschaften das komplette Gebäude betreffen, zum Beispiel beim oben genannten Aldi, Schulen, Hotels usw., setze ich die Eigenschaften immer auf die Fläche. Wenn ich doppelt gemappte Pois entdecke (keepright meckert), einmal als POI und einmal auf der Fläche, habe ich bisher den POI immer gelöscht.

Ich sehe es eigentlich genauso wie meine beiden Vorposter. Ein POI kann eine Fläche sein. Ein Restaurant ist immerhin kein Punkt, sondern vermutlich ein ganzes Haus, oder ein Teil dessen. Zumindest hat es eine Ausdehnung. Wir würden viel Informationen verlieren, wenn wir das alles nur als einen Punkt mappen (Name “Point of Interest” ist dabei irrelevant. Nenne es in Zukunft doch “Polygon of Interest” ;)). Dabei meine ich, dass vielleicht mal jemand kommt und fragt, wie viel m² Verkaufsfläche ALDI wohl hat (OK, ausm Hut gezogen, aber mit Fantasie lässt sich da was machen). Ich denke eher, Punkte mappen ist falsch, weil das gibt die Realität einfach weniger wieder. Und OSM will die Realität darstellen. Willst du den Eingang von ALDI, dann mappe ihn doch mit entrance = yes. Und fertig :slight_smile:

In puncto Einfachheit gebe ich dir allerdings Recht. Irgendwie. Letztlich ist das aber eher eine Frage der API (vielleicht sollte es eine einfache Möglichkeit der Abfrage geben: “Gib mir alle POIs eines Typs” liefert vielleicht auch die Zentroide der Polygone mit… Als erster naiver Ansatz. Und dann hast du wieder deine Punktsammlungen). Ich bleibe dabei: Sicherlich ist durch den Ansatz “Realität mappen” nicht immer allen in optimaler Weise geholfen, aber daran sollten wir uns doch eher halten als an “möglichst einfach auszuwerten”.

Dann redefiniere ich jetzt kurzerhand die Abkürzung POI als “Point/Polygon Of Interest”. Problem gelöst.

Ich finde auch, dass die Eigenschaften immer an eine Fläche gehören, es sei denn eine Fläche wäre durch unzureichende Genauigkeit der Quelle unsinnig.
Wir erstellen hier Daten, die die Geographie der Welt widerspiegeln sollen. Dazu gehört auch, dass z.B. ein Restaurant tatsächlich auch eine Fläche ist, denn es erstreckt sich über einen Bereich.
Ein Restaurant als Punkt ist lediglich eine Abstraktion davon, für wessen Erzeugung wiederum auswertende Programme zuständig sein sollen.

Ist eine deutschlandweite Ausbreitung. Ich setze die Info ans DE-Polygon :smiley:

+1 Mach ich ganz genau so wie du :slight_smile:

+1 Gute Idee, wäre ja nicht die erste Definition die mit der Zeit gehen muss :smiley:

Moin,

bleiben wir mal bei dem Restaurant. Das ist zunächst mal nur ein Gebäude, das kann man auch so mappen. Damit bilden wir die Realität doch gut ab? Was darin nun passiert, also die Nutzung muss doch nicht an das Gebäude gebunden werden. Ja, man kann das, das sieht man auch oft, ich stelle aber genau das zur Diskussion. Es gibt praktische Gründe, das nicht zu tun. Es ist nicht schlechter, den POI als Punkt zu setzen, macht aber einiges einfacher. Warum die Attribute zum Gebäude, wo ist der Vorteil?

LG,

-moenk

Das Gebäude ist ein Hotel → in diesem ist eine öffentliche Gaststätte. building=hotel mit name, phone, website, addr:… und Gaststätte ist ein node mit phone, website, … (falls abweichend) - In dem Hotel gibt es noch einen Frisör … ( noch ein POI)

Moin Geri,

Du zeigst mit Deinem Beispiel genau auf, warum die gängige Praxis Käse ist. Das Gebäude ist ein Gebäude und das hat ganz andere Attribute, die nicht vermischt werden sollten. Darin sind die POI, die sich sogar verorten lassen. Über den Stuss mit building oder area gleich yes oder sonstwas werde ich mich an dieser Stelle nicht weiter aufregen, das hat sich mit einer neuen API hoffentlich auch erledigt.

LG,

-moenk

Für unausgereifte Anwendungen, die nur mit Punkten umgehen können, besteht ja die Möglichkeit, die Umwandlung Weg/Relation → Knoten nach dem Herunterzuladen durchzuführen. osmconvert ermöglicht das schon out-of-the-box mit der Option --all-to-nodes; und ich würde mich nicht wundern, wenn mittelfristig auch die eierlegende Wollmilchsau genannt Overpass API ähnliches anbieten würde. Ich sehe nicht, warum OSM seine Abbildung der Realität kastrieren sollte, um einigen unbedarften Nutzern zwei Zeilen Code zu ersparen.

Oli-Wan,

es geht doch erstmal nicht um Anwendungen, sondern um ein sauberes Datenmodell. Mir kommts auch gleich wieder hoch wenn ich die Arroganz in Deinem Zeilen da herauslese. Sollen die anderen doch sehen wie sie mit unserem Murks klar kommen, wir machen das so wie wir das praktisch finden, gibt doch hier ein Tool und da eine Funktion, alles ganz einfach, sind doch nur zwei Zeilen Code, Pipifax, wir sind genial und ihr seid alle Pfuscher - so einfach geht das nicht!

Das ist aber auch nicht die Frage. Ich finde dass die wirtschaftliche Nutzung des Gebäudes nichts in seinen Attributen zu suchen haben muss. Vermehrt wird das aber bevorzugt so gemappt und auch als korrekt propagiert.

LG,

-moenk

Geht es nun um Anwendungen oder nicht?

Wer unsere Daten nutzen will, kommt nicht umhin, sich mit dem verwendeten Datenmodell zu beschäftigen. Und auch mit der Tatsache, daß die Erfassungsarten ebenso wie die Datenqualität nun einmal sehr inhomogen sind. In der Regel wird er auch nicht daran vorbeikommen, die Daten für seine Zwecke aufzubereiten.

Bei einem Gebäude, das ausschließlich ein Restaurant, eine Bank, einen Supermarkt, ein Hotel, eine Hochschuleinrichtung, eine Autowerkstatt, … beherbergt, ist das Gebäude für mich synonym mit dem jeweiligen Objekt. Wollte man Nutzung und Gebäude trennen, dürfte man konsequenterweise auch keine - postalischen! - Adressen an Gebäude taggen (siehe aktuelle Inkarnation des ewigen Themas im Nachbarfaden) - schließlich schreibt man ja den Bewohnern bzw. dem dort ansässigen Unternehmen einen Brief, nicht dem Gebäude selbst.

Hier ist zu beachten, das gleichzeitig alle Wege und Relationen entfernt werden.
Möglicherweise ist dies nicht das, was man möchte …

Ansonsten halte ich es für essentiell wichtig, daß Objekte nicht doppelt erfaßt werden / sind.
Also sowohl an einem Way (Polygon) als auch an einem Node.

Gruß Klaus

Oli-wan,

genau so isses. Das Gebäude hat andere Attribute, wie Höhe, Anzahl der Stockwerke, Dach, vieles mehr. Mit der Hausnummer bin ich auch als Punkt einverstanden, ein Gebäude kann auch mehrere haben. Hier sollte vielleicht auch eine klare Vorgabe her. Das bringt uns aber etwas vom Thema ab.

Ich halte immer noch die Zuweisung der POI-Attribute an das Gebäude für falsch. Das ändert nichts daran, dass ich die Vorgehensweise anderer akzeptiere, aber das OSM-Datenmodell für dringend reformbedürftig halte. Es geht um saubere Datenstrukturen, der durch die Crowd entstandene Wildwuchs wird für mich immer unerträglicher. Aber sonst scheint sich um sowas im Forum kaum jemand Gedanken zu machen. Alle Argumente gehen für mich in die Richtung “weil man das so machen kann”.

LG,

-moenk

Moin Klaus,

am besten nur als POI :wink:

Doppelt passiert, wir wissen alle warum, und das wird immer wieder passieren.

Danke an dieser Stelle für das Paket zum Jahresende!

LG,

-moenk

Auch, wenn ich schon in wenigen Fällen POIs an Flächen gepappt habe, stimme ich moenk voll zu. POIs gehören in einen einzelnen Node. Mir ist gerade kein Beispiel eingefallen, wo es Vorteile bringt, das nicht zu tun. Es ist einfacher auswertbar und würde sich auch einfacher pflegen lassen. Es geht zwar auch mit Flächen, die Auswertung wird aber verkompliziert - auch wenn es nur eine Zeile Code oder nur ein einzelner Buchstabe im Code ist. Wenn es einfacher geht, weshalb dann nicht einfacher machen?
Ich werde in Zukunft POIs als einzelne nodes taggen.

Dancingman,

danke für Deine Unterstützung - “ganz einfach” isses übrigens gar nicht, nur in bestimmten Szenarien lässt sich die Auswertung mit relativ wenig Aufwand machen. Frag mal einer die Wheelmapper was die für ein Rad drehen mussten.

LG,

-moenk

@moenk: Machen wir das mal anders herum. Mit Polygonen hast du die Möglichkeit, dem Restaurant eine Fläche zu geben. Wenn wir jetzt komplett auf Punkte umsteigen würden, wie würdest du dann irgendwann (man weiß ja nie, vielleicht bekommen wir ja irgendwann Pläne von Gebäuden auf einem Level 20 oder so) die Fläche angeben?

Generell verstehe ich dein Anliegen vom Trennen von Objekt und Nutzung. Kann ich komplett nachvollziehen. Aber wenn das ganze Gebäude ein ALDI ist, die auch die Fläche ein ALDI, also gebe ich der Fläche aktuell den Namen ALDI. Auch wenn es sicherlich nicht so 100% sauber ist. Ich finde es aktuell immernoch besser, die Nutzungsfläche zu taggen, als nur vage da einen Punkt reinzusetzen. Man kann das Tagging auch anders interpretieren: Nicht das building = yes bekommt ein Attribut amenity = supermarket, sondern der Supermarkt ist eben überdacht, also der amenity bekommt als Attribut das building-Tag. Ähnlich wie bei Haltestellen und shelter. Oder man interpretiert es als nebeneinander: Da gibt es ein building und ein amenity auf der Fläche. In beiden Interpretationen ist nichts, was falsch ist… Da ist eher die Landnutzung spezifiziert: Ein überdachter Supermarkt… Finde ich nix schlimmes dran.

Wie gesagt, ich verstehe deinen Einwand, aber er ist meiner Meinung doch sehr engstirnig und einseitig betrachtet. Mir ist es lieb, die Fläche zu erhalten. Und dafür interpretiere ich die Daten, dass es passt - oder besser: Nicht so, dass es nicht passt. Ist irgendwie klar, was ich versuche zu sagen? :smiley:

Hallo,

Ich wäre auch für eine Trennung, denn dieses Erfassungssystem ist nicht konsequent
Befindet sich nur ein POI im Gebäude, dann ans Gebäude, sind es mehrere dann an einen Node, nicht gut :rage:

Warum nicht auch bei einem POI extra an einen Node? Einfach immer, wenn ein POI vorhanden ist, dann an einen extra Node, das würde ich konsequente Umsetzung nennen.

Das gleich sehe ich bei Adressen. Befindet sich in einem Gebäude nur eine Adresse, ans Gebäude, sind es mehrere dann wird an Nodes getaggt. Das ist das gleiche Tagging wie bei den POIs, nicht gut.

Auch hier würde das generelle Erfassen an Nodes eine klare Struktur schaffen und eine einheitliche Erfassung leichter machen. Nicht einmal so und dass wieder so…

Ich finde es einfach logischer und klarer und auch für Neulinge leichter umzusetzen.