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)
Ihr habt Recht! Danke für die Geduld. Es gibt tatsächlich eine Obergrenze für die Anzahl der noderefs: 100.000.
Ich hätte nie gedacht, dass es Wege gibt, die mehr Knoten haben. Hatte das sogar beim Planet getestet und war mir dann sicher, dass es keine Probleme gibt. Das Dumme nur: Die Warnung, die das Programm beim Überschreiten hätte ausgeben sollen, wurde nicht ausgegeben, weil ich statt “>=” einfach nur “>” geschrieben hatte. Sorry.
Die Konstante für die maximale Anzahl steht bei 0.5P in Zeile 8255: oo__refM
Die Warnung, die nicht kommt, steht in Zeile 8993: WARNv(“way %“PRIi64” has too many noderefs.”,id)
Ich werd die Sache weiter untersuchen und den Code anpassen.
Sooo, Version 0.5Q ist oben.
Das Maximum hab ich mal auf 400.000 erhöht. Gebraucht wird das aber bei normalen OSM-Daten nicht. Die neue, erweiterte Statistik zeigt:
$ time ./osmconvert planet-111012.osm.pbf --out-statistics
timestamp min: 2005-05-01T14:56:35Z
timestamp max: 2011-10-12T00:11:00Z
lon min: -180.0000000
lon max: 180.0000000
lat min: -90.0000000
lat max: 90.0000000
nodes: 1228438199
ways: 110885901
relations: 1129925
node id min: 1
node id max: 1463272201
way id min: 35
way id max: 132984869
relation id min: 11
relation id max: 1786401 keyval pairs max: 337
noderefs max: 2000
relrefs max: 7865
real 10m33.786s
user 6m54.680s
sys 0m8.980s
(Nicht wundern, hatte kein aktuelles Planet-File zur Hand und hab deswegen das vom Oktober 2011 genommen.)
@laufkaefer:
Probier bitte mal, ob dir die 400.000 für dein Shape-File reichen. Falls sie nicht reichen, gibt osmconvert jetzt eine entsprechende Fehlermeldung aus. Du kannst in diesem Fall die Konstante oo__refM auf eine Million erhöhen und die Statistik noch einmal starten. Vielleicht kommen wir so langsam auf die benötigte Anzahl an Noderefs.
ich habe grad bei noch einem test (der ja inzwischen nichts mehr beweist) eine kleinigkeit festgestellt: wenn ich ein osm file schneide und das osm ist in irgendeiner (oder allen) richtungen kleiner als das poly, dann verwendet osmconvert die min/max-werte aus dem poly für , die dann natürlich zu klein/groß sind. der mkgmap splitter läuft an der stelle gegen die wand. womit er aber klarkommt, ist gar kein - dann sucht er sich die min/max-werte nämlich selber. ich hab mich grad damit beholfen, einfach per hand zu löschen, besser wäre natürlich, die korrekten werte entweder direkt aus den osm-daten zu holen oder zumindest eine option in der art --omit-bounds-tag zu haben, die das tag unterdrückt.
Habs grad selber gemerkt. Beim Übersetzen für Windows gibts Probleme mit dem riesigen noderef-Feld. Ich werd den Speicher auf eine andere Art anfordern müssen, dazu muss ich das Programm aber ein bisschen umbauen. Für die Zwischenzeit hab ich die Version 0.5R hochgeladen, die zwar noch die erweiterte Statistik drin hat, aber die Anzahl der noderefs wieder auf 100.000 beschränkt. Wenn du unter Linux Experimente machst, kannst du diese Anzahl ja selber erhöhen, das sollte klappen.
Es gibt ab sofort die Option “–max-refs=”, mit der man die maximale Anzahl der Objekt-Referenzen einstellen kann. Klappt auch mit der Windows-Version. Beispiel: