In OSM gibt es verschieden Möglichkeiten (Node, Way oder Relation) POIs einzutragen.
Hinzukommt das man sogar an ein Objekt mehrere POIs unterbringen kann.
Entweder sie haben unterschiedliche Keys oder eben durch Semikolon ( getrennt als Value an ein Key.
Alle die mit solchen POIs arbeiten müssen diese Vielfältigkeit in OSM überwinden.
Ist es da nicht einfacher wenn eine zusätzliche Tabelle existiert die alle POIs auch nur als Punkt zur Verfügung stellt?
Als Spalten in dieser Tabelle würde ich vorschlagen
POI-ID: neue eindeutige ID,
OSM-ID: ID des POIs in der OSM-Datenbank,
OSM-Type: Type des OSM-Objekt (Node, Way, Relation)
POI-Key: Key des POIs z.B. amenity
POI-Value: Value des POIs z.B. school
POI-lat: Mittelpunkt
POI-lon: Mittelpunkt
Diese sollte sich natürlich automatisch bei Eintragung bzw. Löschung eines POIs aktualisieren.
Somit haben Auswerter eine recht einfache Möglichkeit an die Daten heranzukommen.
Wenn sie weiterführende Informationen (z.B. Name) haben wollen kann mit Hilfe von Type und Id aus den restlichen Tabellen in OSM abgefragt werden.
Ich denke in dieser Form ist das nicht wirklich sinnvoll. Denn jedes Objekt ist irgendwie ein POI. Deshalb wird ja in der Regel auch jedes Objekt an einen separaten Node gehängt, wenn an dieser Stelle mehrere Objekte sind.
Für das Eintragen fehlt eher etwas, dass sowohl sagen kann: In diesem Gebäude sind diese x Objekte drin als auch: Dieses Objekt erstreckt sich über diese x Gebäude. Worst Case wäre dann etwa: Ein Hotel erstreckt sich über diese x Gebäude und in dem Hotel gibt es noch eine Bar und ein Restaurant und die befinden sich an Ort y und z.
Heute würde man die Gebäude einzeichnen und dann drei Nodes setzen. Es fehlt aber die Verknüpfung.
auch Du stolpert über die Unzulänglichkeiten des OSM-Datenmodells. POI die nicht als Node gemappt sind finde ich auch umständlich, das wird sich vermutlich aber nicht ändern. Es hilft nichts als sich die Daten zu ziehen und für den eigenen Bedarf so eine Tabelle zurechtzulegen. Oder mit einer gewissen Arroganz POI als Polygone zu ignorieren, in der Hoffnung, dass der Quatsch irgendwann mal aufhört, weil wichtige Objekte irgendwann immer wieder fehlen. Es gibt Fälle wie Parkplätze wo ich den Sinn des Polygons verstehe, es gibt Dinge viel Restaurants und Hotels wo man es auch anders machen könnte, wenn man nicht die Mission hat den Programmierern das Leben schwer zu machen.
Ways als POI sind bei einer Auswertung fast genauso einfach zu behandeln wie “normale” POINTS of Interest (Nodes). Bei Relationen ist es zugegebenermaßen etwas schwieriger.
“select lat,lon from nodes where …” und “select centroid(ways) where …” sind ja nicht sehr verschieden, oder?
Walter, du gehst von einer DB aus. Wenn du es direkt aus einem Extrakt machst, ist es erstmal schon aufwändiger. Wenn man aber nicht nur POI’s extrahieren möchte, ist es wieder egal. Bspw. mkgmap erstellt nebenbei zu jedem Polygon (auch MP) einen Node, wenn man möchte.
Stimmt!
Die Zeiten, wo ich noch mit Garry’s Perl-Scripten Rohdaten verarbeitet habe, sind schon lange vorbei.
Ich würde jedem, der auch nur eine kleine Ecke (Stadt, Kreis) beackern will, raten, sich einen Extrakt zu holen, den durch osm2pgsql zu jagen und den Rest der Arbeit durch professionelle Software (postgis oder spatialight?) erledigen zu lassen.
Wenn man die DB als “Wegwerf-DB” auffasst, braucht man sich nicht um Administration, Daten-Updates, Performance, Backup, … zu kümmern. Daten rein und loslegen.
Kurz noch zum Thema: Aus den Daten eine separate POI-Tabelle aufzubauen, mag ja noch gehen. Aber diese Tabelle dann synchron zu halten mit der sich ständig verändernden OSM-DB, halte ich für nahezu unmöglich. Das geht einfach nicht ohne verdammt viel Arbeit und ist nie 100% exakt.
eine entsprechende Overpass-API-Abfrage für Ways hätte ich gern noch http://overpass-api.de/api/interpreter?data=nodetourism=hotel;out meta;
Als Koordinaten bitte die Zentroiden des Ways, am besten gleich mit dem Union von Ways und Nodes, darf auch als QL und nicht als URL sein.
Und wofür der ganze Quark? Damit man Parkplätze als Fläche mappen kann? Wir müssen allen Anwendern des Zugang zur OSM einfacher statt ihnen das Leben schwer zu machen!
Ja, genau!
Punkt, Punkt, Komma, Strich - fertig ist das Mondgesicht. Aus den Kinderzeiten sind wir längst raus. Flächenartige Objekte mit Eigenschaften werden in Osm nun mal als Fläche mit passenden Tags erfasst.
Der Rest ist Mathematik - und dafür sind die Kisten prima geeignet.
es spricht für mich nichts daegegen eine Hotel-Gebäude als Building mit Polygon und einem Punkt als POI auf dem Eingang zu mappen. Das würde einiges erleichtern die OSM-Daten zu verwenden, die Attribute müssen nicht unbedingt am Objekt liegen.
Ich führe für meine Karten so eine separate Tabelle, wo Nodes und die Mittelpunkte der Flächen einmal täglich zusammengeführt werden. Mein grösstes Problem dabei sind Knoten, die innerhalb von Flächen liegen, aber die gleichen Schlüssel haben. Also der Restaurant-POI innerhalb des Restaurant-Gebäudes. Die sind zwar fast immer unnötig, aber die sind nun mal da.
Bei der Erstellung der Tabelle muss man sich dann entscheiden, ob und falls ja welchen der beiden man wegwirft. Oft sind die unterschiedlich vollständig eingetragen, gelegentlich auch widersprüchlich. Der Zeitpunkt bei der Zusammenführung ist auch der letzte Punkt, an dem die “der Punkt liegt innerhalb der Fläche”-Beziehung noch bekannt ist, später liegen zwei Punkte einfach nur nebeneinander.
Diese Entscheidungen würde ich nicht programmieren wollen für einen Dienst, der von der Allgemeinheit genutzt wird. Da gäbe es mir zu viele Änderungswünsche
Sorry, ich betreibe die DB so wie es Walter in #6 empfiehlt: schwachbrüstiger Server, kleine Region mit 300x230 qkm und das BackupRestore-Konzept ist ein Script zum neu importieren. Meine POIs sind auch nur die, die mich interessieren, die Tabelle soll ja möglichst klein sein. Da fehlen z.B. fast alle Shops. Da hätte keiner was davon.
getrennt als Value an ein Key.