Tool zum POI aus OSM exportieren

[HanZ]

Ja, theoretisch verlierst du all jene Sitzbänke, die als way gemappt sind. Deinen ersten Satz verstehe ich aber nicht so ganz. Nodes sind Punkte, Ways sind Linien. Man kann amenity=bench als beiden kartieren, je nach Sinnhaftigkeit. Eine 20 Meter Bank würde ich eher als Linie (das heißt dann mit Linien zwischen den einzelnen Stützpunkten) mappen, eine einzelne kleine Bank nicht.
Relationen sind Relationen zu anderen Objekten. Einfach Beispiel: Straße mit Gebäude. Dem Gebäude vergibst du eine Relation zu der Straße. Nur topologisch berechnet ist es viel zu aufwändig, das Haus der Straße zuzuordnen, daher wird dem Haus gesagt: IST_BESTANDTEIL_VON: Max-Müller_Straße. Bei einer Auswahl der Straße kann somit jedes Haus sehr schnell zurückgegeben werden.

Bei Bänken macht das kein sind, ist daher auch nicht gefordert, siehe rechts: Used on these elements
https://wiki.openstreetmap.org/wiki/Tag:amenity=bench

In gesamt Bayern sieht die Datenlage wie folgt aus:
Nodes: 63394, Ways: 326, Relations: 0

Ich denke auf die 326 Ways kann man bei 60.000 Nodes verzichten. Zumal das meistens irgendwelche große Bänke in Innenstadt-Parks sind.

 

[theSplit]

Also mit "kürzester Weg" hätte ich "ways" in Verbindung mit "relation" angesehen (ohne die Bedeutung von "relation" betrachtet zu haben, aber eher: relativ zu anderen Sitzbänken?) wie die kürzeste Wegroute von Sitzbank A, zum nächsten Punkt, Sitzbank B - wenn zum Beispiel der Weg oder Luftlinie skizziert wird.

Dass eine Sitzbank aber einmal als Node und einmal als "Way" deklariert wird, ist erst mal komisch. Sie (die Ways) sollten trotzdem als Node auftauchen. Wobei klar, dann wäre die Darstellung auf der Karte vermutlich nicht als (Linien) "Zeichnung" gegeben, wenn ich dich richtig verstehe.

Vermutlich, das habe ich gestern gelesen, gibt es zum Beispiel bei "amenity" die Begrenzung das man es nur mit einem Wert belegen kann, also entweder "Restaurant" oder "Bar". nicht beides und nicht mit beiden Werten und das wird vermutlich auch die Definition ob "Way" oder "Node" betreffen? Schätze ich mal?

Und kleine Randnotiz was ich cool fand:
Ich hatte gestern gesehen, es werden sogar Metadaten wie "Sitzplätze", "Material" (?) und "Farbe" bereitgestellt... schon nett!

 

[HanZ]

Also so ganz kann ich dir leider immer noch nicht folgen, aber ich glaube du hast grundsätzlich das Datenmodell falsch im Kopf.

Lies dir mal diesen Artikel durch:
https://wiki.openstreetmap.org/wiki/DE:Elemente

Dass eine Sitzbank aber einmal als Node und einmal als "Way" deklariert wird, ist erst mal komisch.

Jein. Im Endeffekt ist alles komisch, wenn du es so betrachtest, denn auch eine Ampel ist als reales Objekt kein Punkt, sondern eine Fläche (auch wenn sehr klein). Es geht ja darum die Objekte zu abstrahieren. Und da ist bei einer Bank und der gegebenen Auflösung von OSM Punkt das naheliegenste Wenn du jetzt aber eine lange Bank hast, macht es mitunter auch Sinn, das als Way zu kartieren, da ja auch das gesamte Objekt angezeigt werden soll und nicht nur der Anfang oder Ende oder Mitte.

Sie (die Ways) sollten trotzdem als Node auftauchen. Wobei klar, dann wäre die Darstellung auf der Karte vermutlich nicht als (Linien) "Zeichnung" gegeben, wenn ich dich richtig verstehe.

Linien werde durch mehrere Nodes erstellt. Die einzelnen Nodes KÖNNEN angezeigt werden (daraus besteht die Linie ja), im Regelfall wird aber nur die liniehafte Führung von Punkt A nach B nach C.... visualisiert.

Vermutlich, das habe ich gestern gelesen, gibt es zum Beispiel bei "amenity" die Begrenzung das man es nur mit einem Wert belegen kann, also

Kann ich dir nicht zu hundert Prozent sicher sagen, aber ich denke du liegst falsch. Angenommen ein Hochhaus wird als Gebäude in OSM eingepflegt, und im 1. Stock ist ein Restaurant und im 2. Stock eine Bar. Dann kannst du entweder Nodes in diesem Hochhaus setzen, einen für Bar und einen für Restaurant oder du kannst das Gebäude entsprechend taggen.

das wird vermutlich auch die Definition ob "Way" oder "Node" betreffen? Schätze ich mal?

Wie meinst du das?

es werden sogar Metadaten wie "Sitzplätze", "Material" (?) und "Farbe" bereitgestellt

Bereitgestellt vom Nutzer! Nicht von OSM. In OSM ist erstmal jeglich erdenkliche key:Value-Kombination möglich. Du kannst ein Objekt erstellen und ihm das Attribut "dfhge"="7681" zuordnen. Da wird keine Software irgendeinen Fehler zurückgeben. Bloß gewollt ist es nicht, dafür ist ja auch das Wiki da, damit es da übereinstimmende Definitionen gibt. Aber selbst die sind teilweise sehr mau.

Schau mal hier: https://taginfo.openstreetmap.org/
In ganz OSM gibt es 69.608 verschiedene Keys. Und das ist unabhängig von den Values, da gibt es nochmal bedeutend mehr. Aber nur ein Bruchteil davon wird ernsthaft genutzt. Es gibt z.B. phone="X" aber auch contact: phone="Y". Doppelt gemoppelt. Funktioniert, ist aber nicht schön, da nicht einheitlich.

 

[theSplit]

Also so ganz kann ich dir leider immer noch nicht folgen, aber ich glaube du hast grundsätzlich das Datenmodell falsch im Kopf.

Lies dir mal diesen Artikel durch:
https://wiki.openstreetmap.org/wiki/DE:Elemente

Dass eine Sitzbank aber einmal als Node und einmal als "Way" deklariert wird, ist erst mal komisch.

Jein. Im Endeffekt ist alles komisch, wenn du es so betrachtest, denn auch eine Ampel ist als reales Objekt kein Punkt, sondern eine Fläche (auch wenn sehr klein). Es geht ja darum die Objekte zu abstrahieren. Und da ist bei einer Bank und der gegebenen Auflösung von OSM Punkt das naheliegenste Wenn du jetzt aber eine lange Bank hast, macht es mitunter auch Sinn, das als Way zu kartieren, da ja auch das gesamte Objekt angezeigt werden soll und nicht nur der Anfang oder Ende oder Mitte.

Okay, was ich meine ist nicht explizit die Darstellung auf der Karte direkt als Punkt oder Linien-Formen oder gar Polygon. Sondern die Definition das ich eine Sitzbank einmal als Node finde und einmal als "way" - als Punkt würde ich in diesem Fall nicht nur die kleinste Einheit bezeichnen, sondern auch der Punkt bzw. Ort - wo sich ein Objekt befindet - und das hat ja erst mal nichts mit der Darstellung auf der Karte zu tun. Auch wenn ich den Unterschied verstehe - aber wie gesagt, "Darstellung" für die Karte.

Wobei gut, die Koordinaten geben ja auskunft über den Standort - also eigentlich ist es wohl nur die Darstellung.... wobei, dann weiß man ja nicht, suche ich nach "Objekt" als Way als Node - bzw. ist das vielleicht nicht auch egal? Wenn ich zum Beispiel nur wissen will, "suche mir alle Sitzbänke" - da sollte die Darstellung auf der Karte nichts vorgeben, eigentlich.

Vermutlich, das habe ich gestern gelesen, gibt es zum Beispiel bei "amenity" die Begrenzung das man es nur mit einem Wert belegen kann, also

Kann ich dir nicht zu hundert Prozent sicher sagen, aber ich denke du liegst falsch. Angenommen ein Hochhaus wird als Gebäude in OSM eingepflegt, und im 1. Stock ist ein Restaurant und im 2. Stock eine Bar. Dann kannst du entweder Nodes in diesem Hochhaus setzen, einen für Bar und einen für Restaurant oder du kannst das Gebäude entsprechend taggen.

Da muß ich dich korrigieren ein(!) Objekt/Element kann nur einer Amenity zugeordnet werden laut diesem hier: https://wiki.openstreetmap.org/wiki/Elements#Tag

Aus dem Text:

A tag consists of two free format text fields; a 'key' and a 'value'. Each of these are Unicode strings of up to 255 characters. For example, highway=residential defines the way as a road whose main function is to give access to people's homes. An element cannot have 2 tags with the same 'key', the 'key's must be unique. For example, you cannot have an element tagged both amenity=restaurant and amenity=bar.

Wobei, gut, so wie ich hier lesen kann man einem Element weitere Tags geben, aber es kann jeweils nur einen Schlüssel mit je nur einen Wert/Zuordnung haben (Key ist immer Unique).

das wird vermutlich auch die Definition ob "Way" oder "Node" betreffen? Schätze ich mal?

Wie meinst du das?

Eigentlich einfach, du schreibst ja auch, entweder ich suche nach "nodes" als ein Objekttyp und oder zusätzlich nach "ways". Das sind also zwei Objekttypen. Aber okay, wenn "Node" einen Punkt darstellt und "way" eine Linie - macht es schon Sinn. Zumindest für die Darstellung auf der Karte. Aber ich finde diese Seperation von einem "Punkt" / Ort in Verbund mit der Darstellung auf der Karte unglücklich, eben gerade jedenfalls.

 

[HanZ]

Da muß ich dich korrigieren ein(!) Objekt/Element kann nur einer Amenity zugeordnet werden laut diesem hier

Danke für den Link. Jetzt wo ich drüber nachdenke hätte es mir eigentlich klar sein müssen

Bezüglich der Thematik, was man als Datentyp verwendet, habe ich ein anderes Beispiel, das ich gerade in meiner Bachelorarbeit verwende:
amenity=police kann sowohl ein Punkt als auch eine Fläche sein. Punkt nutzt du dann, wenn du quasi ein POI erstellen willst, der eine Polizeistation markiert. Eine Fläche, wenn das Gebäude eine Polizeiwache ist.
Angenommen aber, du hast jetzt das Rathaus der Stadt Ober-Tüpfelmörbachhausen. In diesem Rathaus ist aber auch eine kleine Polizeistation eingegliedert. Das Rathaus bekommt jetzt amenity=townhall, kann aber nicht auch amenity=police bekommen. Daher kann man das auch auf Nodes verwenden.

Die drei Datentypen sind übrigens rein auf datenbanktechnischen Gründen so wie sie sind. Eine Fläche wird also auch als Line gespeichert. Im OSM-Wiki wird dann aber trotzdem angezeigt, ob man ein Attribut auf Nodes, Ways, Polygone oder Relationen verwenden soll und kann.


Und wenn wir jetzt zurück zur Bank kommen: Da ist Node nunmal der sinnvollste Datentyp, den man verwenden kann, da OSM ja nur einen gewissen Maßstab anzeigt. So weit reinzoomen, dass man die Bank als Fläche erkennen könnte, wäre gar nicht machbar. Und linienhaft ist eine normale Bank auch nicht, vor allem auch für die Darstellung etwas komplizierter/schwieriger zu erkennen.

 

[theSplit]

Und wenn wir jetzt zurück zur Bank kommen: Da ist Node nunmal der sinnvollste Datentyp, den man verwenden kann, da OSM ja nur einen gewissen Maßstab anzeigt. So weit reinzoomen, dass man die Bank als Fläche erkennen könnte, wäre gar nicht machbar. Und linienhaft ist eine normale Bank auch nicht, vor allem auch für die Darstellung etwas komplizierter/schwieriger zu erkennen.

Gut, ich glaube da sind wir uns einig. Mit dem Node/Punkt Ich hab da nur wieder komplizierter gedacht als vielleicht nötig, warum man für "ein und den selben Objekttyp" zwei Datentypen nutzt. Wobei ja, es macht auch Sinn, zumindest wie du es im weiteren erklärst.

Edit:
Wobei, gut, für eine größere Gruppe von Sitzbänken, wäre eine Definition einer "Sitzbank"-Fläche vielleicht sinnvoller. Bzw. besser als 4 Nodes im Abstand von 2 Metern zu taggen

 

[HanZ]

Noch ein anderes Beispiel, dass es verdeutlicht: Der logischste Datentyp für einen Fluss wäre eine Linie. Wenn du jetzt aber den Amazonas mappen willst, dann ist die Linie etwas verloren. Der Fluss ist an seiner breitesten Stelle 300km weit. Ein doppelter Objekttyp, hier also als Linie und Fläche, macht also durchaus Sinn.
https://www.openstreetmap.org/relation/2295651#map=10/-0.4580/-50.9024

 

[theSplit]

@HanZ: Ja, da geb ich dir Recht. - Jetzt ist der Unterschied auch klar dass es mehrere Typen gibt. Muss man aber auch erst mal hinter kommen wie das gedacht ist

 

[wlkr]

Ich habe jetzt die für mich beste Lösung gefunden. Ich erstelle eine Garmin GPI und konvertiere sie dann in eine GPX.
Hier noch der komplette Weg wie ich vorgehe.

1. osmconvert beispiel.osm.pbf >beispiel.osm
2. osmfilter beispiel.osm --keep="amenity=beispiel" >beispiel.osm
3. gpsbabel -i osm -f beispiel.osm -o garmin_gpi -F beispiel.gpi
4. gpsbabel -i garmin_gpi -f beispiel.gpi -o gpx -F beispiel.gpx

Ist es denn möglich mehrere POIs wie Sitzbänke und Schutzhütten in einem Rutsch mit osmfilter zu exportieren?

 

[HanZ]

osmfilter bayern.osm --keep="amenity=bench =shelter tourism=wilderness_hut =alpine_hut" >output.osm

 

[braegler]

gpsbabel -i osm -f beispiel.osm -o garmin_gpi -F beispiel.gpi

Sorry, dieser Schritt leuchtet mir überhaupt nicht ein.
Du hast ein genau spezifiziertes (offenes) Ausgangs-Format, nämlich OSM und ein Zielformat, das ebenfalls öffentlich definiert ist (GPX).
Wieso nun den Zwischenschritt über das durch Reverse Engineering (unvollständig) extrahierte Format GPI (Garmin hat die Spezifikation nie rausgerückt und verweist auf den POILoader will man GPIs erstellen ohne tausende von Euros auszugeben [für den Garmin Content Creator])?

 

[wlkr]

Der Zwischenschritt mit Garmin GPI ist nötig weil wenn ich von OSM direkt zu GPX gehe mir gpsbabel teilweise die einezelnen Punkte als Route ausgibt und nicht als einzelen POI.

EDIT: Den Garmin POI Loader gibt es nur für Windows und MAC aber nicht für Systeme mit dem Pinguin.

 

[braegler]

EDIT: Den Garmin POI Loader gibt es nur für Windows und MAC aber nicht für Systeme mit dem Pinguin.

Wem sagst Du das... für ein Biker-Projekt (Passknacker.com) erstelle ich regelmässig die Garmin POIs. Windoof VM und AutoIT helfen dabei nicht durchzudrehen (Kommandozeilenparameter findet man leider nicht, also bleibt zur Automatisierung nur das GUI-Based Gefrickel.....