Library für OSM-Daten?

rayquaza wrote:

Ich suche eine Library um OSM-Daten zu nutzen. Als Datenquelle sollen zumindest ein Datenbank-Format und OSM-XML, möglichst auch .osm.pbf und die Overpass-API dienen. Die Sprache in der ich schreiben möchte ist C++ und es soll unter Linux, möglichst auch unter Windows ab XP laufen. Durchzuführende Aktionen wären u.A. Ways eines Nodes ermitteln (z.B. um herauszufinden ob zwei Ways zusammenhängen), Objekte innerhalb einer Fläche (auch MPs) ermitteln und ermitteln in welcher Fläche ein Objekt liegt, sowie Längen- und Winkelberechnungen.

Was gibt es da und wie hätte ich suchen müssen um es zu finden?

mir fällt da ganz spontan die libgeos ein. hat zwar keinen direkten OSM-Bezug aber sonst sehr viele Sachen. In dem Umfeld solltest du dich mal ein wenig umsehen, um das Rad nicht völlig neu zu erfinden.

Gruss
walter

wambacher wrote:

rayquaza wrote:

Ich suche eine Library um OSM-Daten zu nutzen. Als Datenquelle sollen zumindest ein Datenbank-Format und OSM-XML, möglichst auch .osm.pbf und die Overpass-API dienen. Die Sprache in der ich schreiben möchte ist C++ und es soll unter Linux, möglichst auch unter Windows ab XP laufen. Durchzuführende Aktionen wären u.A. Ways eines Nodes ermitteln (z.B. um herauszufinden ob zwei Ways zusammenhängen), Objekte innerhalb einer Fläche (auch MPs) ermitteln und ermitteln in welcher Fläche ein Objekt liegt, sowie Längen- und Winkelberechnungen.

Was gibt es da und wie hätte ich suchen müssen um es zu finden?

mir fällt da ganz spontan die libgeos ein. hat zwar keinen direkten OSM-Bezug aber sonst sehr viele Sachen. In dem Umfeld solltest du dich mal ein wenig umsehen, um das Rad nicht völlig neu zu erfinden.

Und mit Boost liegt man (fast) nie falsch.

Gruß Wolf

wambacher wrote:

mir fällt da ganz spontan die libgeos ein. hat zwar keinen direkten OSM-Bezug aber sonst sehr viele Sachen. In dem Umfeld solltest du dich mal ein wenig umsehen, um das Rad nicht völlig neu zu erfinden.

Osmium, das dort unter "Applications using GEOS" gelistet ist, scheint mir relativ passend (lies: andere Vorschläge werden noch angenommen).

Allerdings erhalte ich beim Ausführen der Beispiele folgende Fehlermeldung, mit der ich nichts anzufangen weiss:

terminate␣called␣after␣throwing␣an␣instance␣of␣'std::runtime_error'
what():␣BlobHeader␣size␣invalid:1010792557
Abgebrochen␣(Speicherabzug␣geschrieben)

Der Fehler tritt z.B. an dieser Stelle auf. Als Testdaten nutze ich eine von der OP-API als OSM-XML geladene Buslinie.

rayquaza wrote:

Der Fehler tritt z.B. an dieser Stelle auf. Als Testdaten nutze ich eine von der OP-API als OSM-XML geladene Buslinie.

Sorry, praktische Erfahrung hab ich in der Ecke nicht; ist halt nur sowas, von dem ich weiss, aber es nicht benutze.

Gruss
walter

Wie sieht dein Dateiname für die Eingabedaten aus? Schau mal in folgenden Bug rein: https://github.com/joto/osmium/issues/74

Dieser Fehler kommt, wenn Du Osmium eine XML-Datei gibst, es aber denkt, dass du ihm eine PBF-Datei gegeben hast. Die Datei sollte eine passende Endung haben, z.B. .osm für OSM-XML-Dateien, osm.bz2, wenn gepackt oder .osm.pbf für PBF-Dateien. Dann wird das automatisch erkannt. In Deinem eigenen Code, den Du auf Osmium-Basis schreibst, kannst Du aber auch bestimmte Formate erzwingen.

Die Programme im Example-Verzeichnis sind sehr simple Beispiele, daher haben sie keine vernüftigen Fehlerchecks.

Nach Deiner Beschreibung ist Osmium genau das richtig für Dich für das Lesen und Verarbeiten der OSM-Daten. Osmium kann dann GEOS-Geometrien erzeugen, mit denen Du die weitere Verarbeitung machen kannst. Der Windows-Support von Osmium ist nicht perfekt. Ich hab diverse Patches für Windows schon eingebaut, aber es geht nicht alles.

Uns fehlt ein Kopf-gegen-Wand-Smiley. Ja, "out" hiess es, danke für die Hinweise. JOSM kann das btw auch nicht. Für zukünftige derartige Fehlermeldungen (in vollständig eigenem Code): Wo wird denn dieser Speicherabzug hingeschrieben? Googeln bringt da leider nichts, weil überall diese Fehlermeldung aber nirgens diese Information steht…

Jochen Topf wrote:

Der Windows-Support von Osmium ist nicht perfekt. Ich hab diverse Patches für Windows schon eingebaut, aber es geht nicht alles.

Danke für die Warnung. Windows-Unterstützung ist für mich eh nicht so wichtig.

rayquaza wrote:

Wo wird denn dieser Speicherabzug hingeschrieben?

Probier zunächst mal ulimit -a bzw. ulimit -c, ob core-Files überhaupt geschrieben werden sollen. Oft ist der Vorgabewert mit 0 belegt, also kein core File schreiben. Ein ulimit -c unlimited sollte weiterhelfen.

couchmapper wrote:

Probier zunächst mal ulimit -a bzw. ulimit -c, ob core-Files überhaupt geschrieben werden sollen. Oft ist der Vorgabewert mit 0 belegt, also kein core File schreiben. Ein ulimit -c unlimited sollte weiterhelfen.

Das beantwortet meine Frage, danke.

Ich habe nun etwas mit dem mpdump-Example gespielt und lasse mir dort (etwa Zeile 36) die Fläche und die Länge (=Umfang) mit folgendem Code ausgeben:

multipolygon.borrow_geos_geometry()->getArea()
multipolygon.borrow_geos_geometry()->getLength()

Nun sind allerdings die Fläche wohl in °² und die Länge in etwas ebenso nützlichem und ich finde nichts, um das in SI-Einheiten zu erhalten. Nach dem was ich bisher herausgefunden habe müsste das wohl vor dem Erhalt der GEOS-Geometrie geschehen.

multipolygon.borrow_geos_geometry()->getSRID() gibt -1 aus, obwohl hiernach bei OSM-Daten die SRID normalerweise 4326 ist. Hat das was damit zu tun oder ist das normal?

rayquaza wrote:

Ich habe nun etwas mit dem mpdump-Example gespielt und lasse mir dort (etwa Zeile 36) die Fläche und die Länge (=Umfang) mit folgendem Code ausgeben:

multipolygon.borrow_geos_geometry()->getArea()
multipolygon.borrow_geos_geometry()->getLength()

Nun sind allerdings die Fläche wohl in °² und die Länge in etwas ebenso nützlichem und ich finde nichts, um das in SI-Einheiten zu erhalten. Nach dem was ich bisher herausgefunden habe müsste das wohl vor dem Erhalt der GEOS-Geometrie geschehen.

multipolygon.borrow_geos_geometry()->getSRID() gibt -1 aus, obwohl hiernach bei OSM-Daten die SRID normalerweise 4326 ist. Hat das was damit zu tun oder ist das normal?

Der erste Teil deines Problem Multipolygon -> Flächenmaß ist ja immerhin gelöst. Jetzt kommen die vielen lästigen Details.

Das -1 als Rückgabewert deutet darauf hin, dass SRID innerhalb deiner Abfrage nicht gesetzt ist. In der OSM Datenbank sind alle Koordinaten nach WGS84 enthalten. In deiner Datenbank kann das beim Import gegebenenfalls schon nach Mercartor umgewandelt worden sein. Das kann man von außen nicht wissen. Wie auch immer scheint dieser Wert nicht gespeichert oder so nicht zugreifbar zu sein.

Da ich mich mit Osmium nicht auskenne, kann ich leider nur zu den offensichtlichen Dingen etwas sagen, dir aber keine Vorschläge zur Lösung anbieten.

Edbert (EvanE)

EvanE wrote:

Der erste Teil deines Problem Multipolygon -> Flächenmaß ist ja immerhin gelöst.

Entweder hab' ich zu verwirrend geschrieben oder du zu schnell gelesen:

rayquaza wrote:

[…] in °² und […] ich finde nichts, um das in SI-Einheiten zu erhalten.

EvanE wrote:

In deiner Datenbank kann das beim Import gegebenenfalls schon nach Mercartor umgewandelt worden sein. Das kann man von außen nicht wissen.

Ich lese direkt aus OSM-XML-Dateien – Wie geschrieben: Das Beispiel nur geringfügig modifiziert.

Das nächste Problem ohne Lösung kommt auch gleich nach: Wie komme ich von einer Relation aus auf die Objekte der Member (z.B. weil ich die Knoten eines Weges aus einer Relation, die in einer bestimmten Relation ist will)? Gibt es zu sowas ein Beispiel?