Osmosis-Problem: OSM und SRTM von Deutschland zusammenfügen

Hallo,

ich habe folgendes Problem mit osmosis:

Ich wollte die OSM- und SRTM-Daten von Deutschland mit osmosis mergen:
osmosis --rb osm.pbf --rb srtm.pbf --m --wb osm_srtm.pbf
Osmosis arbeitet eine zeitlang, bis die Zieldatei sich nicht mehr verändert, sobald sie ca. 905,6MB groß ist.

Dann habe ich einfach mal die .pbfs in .osms umgewandelt und das ganze nochmals mit sortieren probiert:
osmosis --rx osm.osm --rx srtm.osm --s --m osm_srtm.osm
Osmosis beendet sich dann nach kurzer Zeit mit der Fehlermeldung “Cannot represent 7??? as a char” (die genaue Zahl weiß ich nicht mehr)

Gibt es für dieses Problem eine Lösung?

Wie Du hier siehst, hatte ich das Phänomen auch schon. Das Problem scheinen die zu großen Dateien darzustellen, merge einen kleineren Bereich und es wird funktionieren. Aber ganz Deutschland wird nicht funktionieren. Wieviel Gigabyte (entpackt) willst Du denn da mergen? Hast Du soviel Arbeitsspeicher? Beobachte mal wieviel Arbeitsspeicher Osmosis während des Vorgangs in Beschlag nimmt, z.B. mit dem Task-Manager wenn Du mit Windows unterwegs bist. Wie gesagt es ist lediglich eine Vermutung, denn die Fehlermeldungen von Osmosis sind nicht gerade ein “offenes Buch”.

Edit: Woher hast Du den die Höhendaten im pbf-Format (srtm.pbf)? Gibt’s da neuerdings was anderes außer SRTM2OSM?

Ja, das hatte ich auch schon gelesen. Ich dachte es könnte mittlerweile schon eine Lösung für dieses Problem geben.
Das mit dem Arbeitsspeicher werde ich mal beobachten. Mit dem pbf-Befehl wird die Datei ja immerhin schonmal 900 von 1200MB groß. Im XML-Format sind die Dateien natürlich viel zu groß für den Arbeitsspeicher (ca. 25GB). Aber mit diesen kommt es garnicht soweit, dass viel Arbeitsspeicher gebraucht wird, denn die Fehlermeldung erscheint schon bei einer Arbeitsspeicher-Nutzung von 40MB.
Die Höhenlinien sind schon von Srtm2Osm, ich habe sie eben ins OSM-0.6-Format migriert und dann als pbf gespeichert.

Hallo!

Ein paar Fragen zum Verständnis… und um meine Ahnungslosigkeit in Sachen Höhenlinien zu bekämpfen. :slight_smile:

Sind die umgewandelten Höhenlinien sowas wie geschlossene Polygone, die als “Ways” abgespeichert sind? Falls ja, müssten ja neue Nodes erstellt worden sein. Welche IDs haben sie, bzw. welchen ID-Bereich nutzen sie? Gibt es Konflikte mit bestehenden Nodes?

Wenn die Dateien im .osm-Format vorliegen, sind sie so wie üblich sortiert? Also, zuerst alle Nodes, dann alle Ways, dann alle Relations; innerhalb jedes OSM-Objekttyps aufsteigend nach ID sortiert?

Das ist nicht (mehr) das Problem, siehe hier
Sortiert müssten sie auch sein, aber ich kann das ja mal mit
osmosis --rb srtm.pbf --s --wb srtm_sorted.pbf
sicherstellen.

Ah, danke!
Wenns mit Osmosis auf deiner Hardware gar nicht klappen will, kannst du das relativ alte (und eventuelle nicht so flotte) osmchange nehmen:
http://wiki.openstreetmap.org/wiki/DE:Osmchange_%28program%29

osmchange <datei1.osm datei2.osm >mischung.osm

Dazu müssen die Eingangsdateien aber unbedingt sortiert sein. Lässt sich mit osmchange -t testen, wenn ich das noch recht in Erinnerung hab.

Schneller, weil eine der Dateien ein PBF-File sein darf (oder beide auch .o5m), ist osmconvert, aber damit sei bitte noch vorsichtig, es ist recht neu und noch nicht in jeder Hinsicht getestet.
http://wiki.openstreetmap.org/wiki/DE:Osmconvert

osmconvert datei1.pbf datei2.osm >mischung.osm

Beide Programme haben den Vorteil, dass sie deutlich weniger als 1 GB Hauptspeicher beanspruchen - unabhängig von der Größe der Eingabedateien.

Sonstige Plausibilitätsprüfungen darfst du bei diesen Alternativen aber nicht erwarten, sie mischen die Daten einfach - ohne Rücksicht auf Verluste. :wink:

Danke für den Vorschlag.
Diese Programme werde ich später auch noch testen, wenn mein folgender Lösungsweg zum gewünschten Ergebnis führt:


head -n -1 osm.osm > osm_withoutendtag.osm
tail -n +4 srtm.osm > srtm_withoutstarttag.osm
cat osm_withoutendtag.osm srtm_withoutstarttag.osm > osm_srtm.osm
osmosis --rx osm_srtm.osm --sort --wb germany.srtm.osm.pbf

Sollte das funktionieren?

Edit: Für Windows-User:
Der 1. Befehl entfernt die letzte Zeile aus der osm.osm (den osm-close-tag) und speichert das Ergebnis in die Datei osm_withoutendtag.osm,
der 2. entfernt die ersten zwei Zeilen (den osm-start-tag und das bounds-Element) aus der srtm.osm und speichert das Ergebnis in die Datei srtm_withoutstarttag.osm,
der 3. fügt die eben erstellten Dateien zu osm_srtm.osm zusammen und
der 4. sortiert das ganze schließlich und speichert es als germany.srtm.osm.pbf

Ich bräuchte ein alternatives Programm zu Osmosis, das OSM-Files sortiert, weil Osmosis bei dem letzten Befehl meiner oben beschriebenen Vorgehensweise wieder mit der Fehlermeldung “Cannot represent 74334 as a char.” abbricht. Das passiert immer dann, wenn ich OSM-Dateien sortieren will. Vielleicht würde es ja mit einem anderen Programm funktionieren.

Ich würde allerdings trotzdem gerne wissen, wodurch die Fehlermeldung überhaupt verursacht wird? Was ist mit 74334 gemeint? Ist es eine Zeichen- oder Zeilenangabe? Weiß das einer von euch?

Hallo,

Hat mittlerweile einer eine Lösung zu dem Problem gefunden? Ich sitze auch gerade davor meine OSM-Daten mit SRTM Höhenlinien auszustatten.
Ich meine die Ursache gefunden zu haben, nämlich, dass Srtm2OSM einfach Wege mit viel zu vielen Nodes schreibt, das würde auch die Werte knapp über 65.535(maximaler Bereich von char in Java) erklären. Noch klarer wird das Ganze wenn man sich den Source an der Stelle anschaut:

sw.writeCharacter(IntAsChar.intToChar(wayNodes.size()));

Erlaubt sind ja so wie ich das in Erinnerung habe maximal 2000.
Um dem auf die Spur zu gehen hab ich mir mal die Ausgabe von Srtm2OSM bei einem kleinen Testbereich angeschaut, und es werden tatsächlich Wege mit über 2000 Nodes generiert

Found segment with 2249 vertices

Also müsste man vermutlich Srtm2OSM umändern/schreiben um es OSM-konform zu machen.
Ich hab jedoch wenig Ahnung von C# und den Aufbau von Srtm2OSM um das Ganze mal schnell zu machen. Vieleicht findet sich ja hier jemand der in das Projekt involviert ist, der das Problem lösen könnte.

Gruß
Philipp

Ist es unbedingt erforderlich “Srtm2OSM” zu verwenden ?

Gruß Klaus

Ich bin für andere (am besten ähnlich “einfache”) Lösungen gerne offen. Jedoch muss am Ende eine OSM-Datei mit Konturen rauskommen, da ich diese mit mapsforge weiterverarbeiten möchte um Vektorgerenderte Höhenlinien zu bekommen. Das klappt soweit auch ganz gut, mit wesentlich kleineren Bereichen(wo einfach die Konturen nicht an diesen Datentyplimit stoßen).
Ich hab auch schon eine andere Lösung probiert die soweit auch gut funktioniert hat, aber es war eine Sauarbeit, da ich den Umweg über Shapefiles/gdal_contour/shp2osm(was ich teilweise noch umschreiben musste) genommen habe, da wäre ich mit so einer Lösung wie Srtm2OSM schon ganz zufrieden.

Gruß
Philipp

Hi,

SRTM2OSM wird vom Autor nicht mehr weiter entwickelt, weil er selber was besseres entwickelt hat, Groundtruth. ist aber möglicherweise nicht mehr open source.

Alternativ wurde in jüngster Zeit phyghtmap entwickelt.

Gruß,
ajoessen

Ja, das Tool “phyghtmap” wäre auch meine Empfehlung.
Link: http://katze.tfiu.de/projects/phyghtmap/
Es gibt hier zu “phyghtmap” auch einen Thread.
Fragen zum Tool am besten dann dort stellen.

Gruß Klaus

Achtung, nur nicht dabei viewfinderpanoramas.org Daten verwenden, dann begehst du so wie toc-rox (Klaus) eine Lizenzverletzung…:mad:

per aspera ad ACTA!

@ajoessen,toc-rox
Vielen Dank,
warum renn ich eigentlich so engstirnig durch die Gegend und bastle mir Murks mit völlig veralteten Programmen zusammen -.-
phyghtmap ist für meine Bedürfnisse -perfekt-! Genau so was hab ich gesucht! Das Ganze ist wesentlich ressourcensparender als den Kram den ich mir davor zusammengebaut habe.
@extremecarver
Keine Angst ich habe nicht vor irgendwelche Höhendaten in Openstreetmap einzutragen, das Ganze geschieht für die private “offline-contour-vektor-rendering-map” über mapsforge in Oruxmaps(kann man nur empfehlen :)). Soweit wie ich das sehe ist das nach deren “Terms of Use” erlaubt…

Gruß Philipp

Ja, man darf aber auch nicht OSM-Daten mit den viewfinderpanoramas.org-Daten zusammen unter einer Lizenz veröffentlichen, da die beiden Lizenzen derzeit inkompatibel sind. Solange du also das Produkt nicht mischt oder aber nicht veröffentlichst ist derzeit alles gut…

Das mergen ist nun mal ein mischen. Und laut CCBYSA 2.0, wird jeder Datensatz den du mit CCBYSA 2.0 mischst, nun eben auch zu CCBYSA 2.0. Ergo kann man die Daten nicht zusammen veröffentlichen, da dies eben inkompatibel ist. Unter odbl ist es dasselbe - da man in dem Fall die viewfinderpanoramas.org Grunddaten unter odbl veröffentlichen müsste, was auch wiedrrum nicht möglich ist. (nicht klar ist mir, ob es unter odbl erlaubt wäre, wenn man nur Rasterendprodukte veröffentlich, Garmin Karten sind aber Vektorkarten, also eine neue Datenbank welche unter odbl stehen muss).

Gut zu wissen, dann hüte ich mich davor die viewfinderpanoramas.org-Sachen zu veröffentlichen…
Aber ein Produkt aus normalen (US-)SRTM darf man unter (nehm ich mal an) der odbl veröffentlichen bzw. unter einer Community verteilen?
Und noch eine Frage:
Wäre es denn wenigstens erlaubt ein Screenshot mit den gemischten Daten zu veröffentlichen, oder müsste dieser dann auch schon komplett unter der odbl veröffentlicht werden, so, dass er nicht mehr zulässig wäre?

Über Umwege müsste es mit der ODbL gehen. Du machst ein Bild aus Höhendaten mit der Lizenz “nur für Privat”, ein Bild aus OSM mit “nur für Privat” und dann verbindest du diese zu einem Werk mit “nur für Privat”. Du kannst aber nicht die Höhendaten und die OSM-Daten zu einem Bild rendern und dann mit “nur für Privat” weitergeben.