der linke screenshot ist mit srtm2osm → mkgmap splitter → mkgmap erzeugt, der rechte mit srtm2osm → osmconvert → mkgmap splitter → mkgmap, ausgangsdaten sind in beiden fällen gleich.
änderungen der optionen bei osmconvert (mit/ohne --complete-ways, andere poly-files) bringen keine veränderung.
Hi!
Hast du mal ein diff über die Ausgabedaten von “mkgmap splitter” und “osmconvert” laufen lassen? Vielleicht ist ja alles da und es gibt nur Format-Probleme?
Liefer doch bitte die kompletten Kommandozeilen für beide Fälle nach. Ohne die ist eine genauere Hilfe arg schwer…
Die Frage wäre ja erstmal welche Wege da verloren gehen?
Bisher ist nur klar, dass diese aus srtm Daten stammen. Wichtig wären jetzt vielleicht kleinere Ausschnitte aus beiden Dateien.
Omsconvert hat früher auch mal Relationen ohne Member entfernt. Vielleicht sind diese Wege mit einem anderen ungewöhnlichen Merkmal ausgestattet.
diff ist schwierig, weil aufgrund der verschieden großen ausgangsdaten für den splitter damit auch verschieden große kacheln erzeugt werden - ich hab also nichts, was ich vergleichen kann, ausser dem endergebnis.
ich werde aber mal ein diff der ungeschnittenen und der geschnittenen ausgangsdaten erzeugen - alles was da innerhalb meines poly differiert, wäre verlorengegangen, sehe ich das richtig?
Danke! Jetzt kann ich mir eher was drunter vorstellen.
Woher hast du die Polygon-Dateien? Da die beiden nur im Zweig mit osmconvert verwendet werden, könnte der Fehler auch hier die Ursache haben.
Kann sich da ein Fehler eingeschlichen haben? Sind dort mehrere sich überlagernde Polygone drin? Oder ist einer der Außenpunkte extrem verschoben?
Falls es sich nicht um vertrauliche Daten handelt, könntest du sie vielleicht posten…?
Danke! Sehen wirklich völlig ok aus.
Oben im Script steht was von “ml-india01.poly”, dein Beispiel heißt “india03.poly” - ich hoffe, das passt trotzdem zusammen.
Gibts ein Fehler-Szenario, das ich selber allein mit osmconvert nachspielen könnte?
ja, das passt, dateiname und regions-bezeichnung in der datei werden nicht abgeglichen und können beliebig sein.
nachspielen ist momentan schwer, weil die ausgangsdaten fast 7 gb gross sind - kann ich nicht hochladen. ich werde im laufe des nachmittags/abends mal versuchen, ein szenario in klein zu bauen, 1x1 grad oder so, gucken, ob der fehler damit reproduzierbar ist und gegebenenfalls mal was hochladen.
ich habe die ungeschnittenen und die geschnittenen ausgangsdaten mit dem mkgmap splitter mal in gleiche kacheln geteilt, dann --diff und --out-statistics auf vergleichbare kacheln angewendet (und zwar eine kachel aus der mitte, die die begrenzung nicht berührt und damit nicht geschnitten wird)
ergebnis:
–diff: kein unterschied
–out-statistics: exakt die gleiche zahl nodes, ways fehlen ca. 10 von knapp 17.000, damit kann man leben
trotzdem ist die eine kachel ca. 90 mb kleiner als die andere. was nämlich fehlt sind unmengen an tags. da werden dann natürlich auch die linien nicht gerendert.
ich hab’s anhand dateigröße und durchschnittliche zeichenzahl einer nd-ref-zeile mal überschlagen, es gehen in einer ca. 250mb großen datei etwa 4 mio. nd-refs verloren.
Noderefs darf das Programm nur dann verwerfen, wenn die Option --drop-broken-refs verwendet wird. Ohne diese Option dürfte keine einzige Referenz ausgeschlossen werden. Falls das doch passiert, stimmt mit dem Programm etwas nicht.
Fragen:
Welche Version von osmconvert verwendest du?
Wär es dir möglich, die Eingangsdatei zur Verfügung zu stellen, damit ich selber einen Test durchziehen kann?
Tritt das Problem auch dann auf, wenn du die .osm-Datei vorher in eine .o5m-Datei umwandelst? Beispiel:
und die beiden (Lat49Lon11Lat50Lon12.osm & Lat49Lon11Lat50Lon12-nbg.osm) im JOSM “optisch verglichen”
(deshalb brauchte ich auch das “–fake-version”)
(“nbg” steht für Nürnberg, oh wie verwunderlich
Konnte jetzt da keinen großen Unterschied sehen:
Klar, sobald auch nur ein Punkt eines Weges außerhalb der Stadtgrenze (nbg-grenze.osm) war, ist der komplette “Weg” futsch.
Klar ist auch, dass Nürnberg - da relativ flach - jetzt nicht das tolle SRTM-Gebiet ist.
Ob jetzt der indische Subkontinent in meinen JOSM passt, wage ich zu bezweifeln
Dass grenzüberschreitende Wege komplett fehlen, liegt an JOSM. Wenn das way-Objekt eine Referenz zu einem Objekt enthält, das nicht mehr in der Datei ist (z.B. ein Knoten, der außerhalb des Gebiets liegt), dann ignoriert JOSM den way komplett. Das lässt sich verhindern mit “–drop-broken-refs” (schneidet solche Ways einfach ab) oder mit “–complete-ways” (nimmt die Wege in ganzer Länge mit).
Was mir grad einfällt:
Gab es im Fall Indien irgendwelche Fehlermeldungen von osmconvert? Reicht vielleicht die maximale Anzahl von Nodes pro Way nicht? Was ist die höchste und die niedrigste ID eines Objekts (node oder way)?
so, hat bissel gedauert, aber josm brauchte je ne halbe stunde, um die großen dateien zu öffnen
versuchsanordnung:
1.erzeugen der “masterdatei” mit srtm2osm: srtm2osm.exe -bounds1 15 68 22.4 89.5 step 20 -cat 500 100 -large -corrxy 0.0005 0.0005 -o india04.osm, ergebnis: eine datei mit ca. 4,6 gb (kann ich nicht hochladen)
schneiden der masterdatei mit dem weiter oben geposteten poly: osmconvert india04.osm -v=2 -B=india04.poly --complete-ways >india04-c.osm, ergebnis: ca. 3,5 gb
per gpsmapedit einen verlorenen way gesucht, per josm den id einer node dieses way herausgefunden
per texteditor die node gesucht und in beiden files gefunden, abgesehen von der rundung durch osmconvert sind die nodes gleich
die zugehörige noderef gesucht und nur in der ungeschnittenen datei gefunden
der mkgmap splitter ist bis hierher nicht eingesetzt, d. h. den können wir als fehlerquelle ausschließen
wer’s nachspielen will, hier zwei deckungsgleiche kacheln (die sind per splitter erzeugt)
–out-statistics liefert für beide kacheln wie gesagt exakt die gleiche zahl an nodes, bei den wegen differiert es um 10-15 wege
ach ja, alles mit der 0.5P gemacht
und der nürnberg-test: ich habe versucht, das problem mit 1x1° nachzubauen - das ging nicht, da war alles ok. ich wage mal die vermutung, das es an extrem langen wegen liegt. die betroffenen wege enthalten auf jeden fall ein paar hundert, wenn nicht ein paar tausend nodes (ich hab nicht wirklich zählen können, weil das scrollen so langsam ging)