Habe den Nachmittag mit dem Versuch verdaddelt, zwei OSM-Dateien zu mergen.
Zuerst kam die Fehlermeldung, dass Osmosis die OSM-Version 0.5 in den Höhendaten nicht passt. Also schnell das alte Osmosis 0.35 installiert und damit die Daten in v0.6 konvertiert:
Osmosis meint, in meinen SRTM-Daten fehlen irgendwelche entity timestamp attributes. Wenn ich mir die Daten mit einem Texteditor ansehe, sind dort aber definitiv Datumsangaben enthalten.
Gleiches Ergebnis mit Osmosis 0.41.
Damit ging garnichts mehr. Das Programm bricht sofort ab. Irgendwo kann ich noch kurz lesen, dass die “Hauptklasse org.codehouse.classworlds.Launcher” nicht gefunden werden kann.
Sieht gut aus. Dank Deines Hinweises habe ich Osmosis zum Laufen gebracht.
Tatsächlich enthielten meine Map-Daten keine TimeStamps. Durch Setzen des Schalters “enableDateParsing=no” im Osmosis-Aufruf wurde die Ausgabedatei erzeugt.
Mich wundert aktuell noch die Tatsache, dass das gemergte File ca. 2.8GByte hat, obwohl die beiden Input-Dateien nur 1.8GByte und 300MByte groß sind. Beides im osm-Format. Ob die Ausgabedatei ok ist, werde ich morgen testen.
Die Dateigröße der Ausgabedatei rührt wohl daher, dass die fehlenden timestamps eingefügt wurden. Mittlerweile generiere ich ein pbf-file, das wesentlich kleiner ist (ca. 150MB).
Eine Sache ist mir noch aufgefallen. Über große Bereiche der Karte werden vereinzelt gerade Höhenlinien gezogen, die definitiv falsch sind. Es sieht aus, als hätte jemand mit einem Lineal über zig Kilometer eine Linie gezogen. Ich meine, das war vorher nicht so.
Einige Element-IDs der OSM-Daten und der Höhenlinien sind gleich. Abhilfe schafft, entweder die Daten getrennt zu lassen und die Höhenkarte als transparentes Overlay zu generieren, oder die Höhenlinien-“Rohdaten” mit IDs zu erzeugen, welche in OSM für lange Zeit nicht erreicht werden - irgendwann klappt das auch nicht mehr.
Verstehe. Kann ich evtl. beim Konvertieren der SRTM-Daten von v0.5 nach v0.6 eingreifen und einen anderen ID-Bereich für die neuen Daten bestimmen?
Was genau wäre mit “Overlay” gemeint? Bislang habe ich mit zwei OSM-Rohdaten-files gearbeitet, Kartendaten und Höhenlinien. Diese habe ich getrennt mit Splitter bearbeitet und erst mit mkgmap zu einer Karte vereint. Dabei waren die Splitter-Kacheln der Höhendaten mit dem Attribut “transparent” vesehen.
Ich wüsste kein Programm, welches dieses tut. Ich kenne die Herkunft Deiner Höhendaten nicht - SRTM2OSM?
Wenn man die Höhendaten aber mit Phyghtmap erzeugt, kann man die Start-ID (ab dieser aufwärts) festlegen.
Mir war nicht bekannt, wofür die OSM-Daten bestimmt waren, “Overlay” war allgemein gemeint, hätte auch die Karte auf einer Webseite sein können. Der Begriff trifft aber auch dein bisheriges Vorgehen - eine zweite, transparent drübergelegte Karte (und abschaltbar). Das würde ich bevorzugen, da aufgrund der Datenentwicklung regelmäßig eine neue Karte erzeugt wird, die Höhendaten aber bleiben gleich.
Würde erst nochmal versuchen, neue Höhendaten mittels Srtm2OSM herunterzuladen. Eigentlich sollte das funktionieren. In der Beschreibung heißt es:
OSM Output
Srtm2Osm stores elevation contours as OSM ways tagged with contour = elevation tag. Also, the ele tag contains the elevation of the contour (in elevation units). The nodes and ways have ID numbers starting from 9,223,372,036,854,775,807 and are decremented for each new element in order to avoid the conflict with the actual data from the OSM server.
If you don’t like this high ID number, you can also set the starting ID with the -firstnodeid and -firstwayid options. If you want the IDs to increment, use the -incrementid option.
Vielleicht kann ich so das Problem beseitigen.
T.
Edit: Scheint nun tatsächlich zu funktionieren. Habe mit einer aktuellen Srtm2Osm-Version (1.12) neue Daten heruntergeladen und die Karte erneut generiert. Bis jetzt sind mir keine Fehler in den Höhenlinien mehr aufgefallen.
nachdem mein Problem mit den Höhenlinien vor einem Jahr gelöst schien, tritt es nun wieder auf.
Ich würde nun gerne kontrollieren, ob sich die ID-Bereiche tatsächlich überschneiden. Gibt es hierfür eine einfache Möglichkeit oder ein Tool?
Falls sich der Verdacht bestätigt, wo sollte man die Parameter -firstnodeid und -firstwayid ansetzen?
“If you want the IDs to increment, use the -incrementid option” → Muss ich -incrementid einschalten?
hab mir den uralten thread niccht komplett durchgelesen aber gesehen, dass du wohl mit .osm files arbeitest.
Das sind reine Textfiles, die du z.B. mit grep durchsuchen kannst. ansonsten könntest du noch osmconvert drauf ansetzen, das Teil hat eine Statistikoption, die einiges ausgibt.
das Thema Höhenlinien hat mich am Wochenende auch schon beschäftigt.
Vielleicht findest du hier etwas, das dir weiterhilft.
Mir wurde dort empfohlen, die statischen Daten mit Osmconvert auszulesen und bei der Verarbeitung der SRTM-Daten zu berücksichtigen.
Die Höhenlinien getrennt zu halten hat den unschönen Effekt, dass sie dann meistens über den Straßen gezeichnet werden.
Ich stecke die OSM und die Höhendaten einfach zusammen in den mkgmap-splitter. Funktioniert wunderbar.
Eventuell muss man “keep-complete=false” einstellen, da muss ich auch noch ein wenig experimentieren.
