Re: Gelöst&Howto: osmconvert "verliert" ways beim schneiden von srtm-daten

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)

2. 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

3. per gpsmapedit einen verlorenen way gesucht, per josm den id einer node dieses way herausgefunden

4. per texteditor die node gesucht und in beiden files gefunden, abgesehen von der rundung durch osmconvert sind die nodes gleich

5. 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)

www.geocaching-dresden.de/srtm1.bz2 (kleineres file, geschnitten)
www.geocaching-dresden.de/srtm2.bz2 (größeres file, ungeschnitten)

--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)