siehe hier:
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.
woran könnte das liegen?
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.
toolchain ohne osmconvert (linkes bild):
srtm2osm.exe -bounds1 8 73 15.4 81 step 20 -cat 500 100 -large -corrxy 0.0005 0.0005 -o india01.osm
srtm2osm.exe -bounds1 15 68 22.4 89.5 step 20 -cat 500 100 -large -corrxy 0.0005 0.0005 -o india02.osm
java -Xmx2000m -jar splitter.jar --cache=cache --mixed --output=xml --geonames-file=cities15000.zip --mapid=632400xx india01.osm
java -Xmx2000m -jar splitter.jar --cache=cache --mixed --output=xml --geonames-file=cities15000.zip --mapid=632400xx india02.osm
java -Xmx2000m -jar mkgmap.jar --max-jobs=2 --latin1 --keep-going --transparent --style-file=style --style=ml-cont --tdbfile --family-id=20028 --product-id=1 --description=in-cont3 --series-name=in-cont3 --family-name=in-cont3 --overview-mapname=in-20028 -c template.args
toolchain mit osmconvert (rechtes bild):
srtm2osm.exe -bounds1 8 73 15.4 81 step 20 -cat 500 100 -large -corrxy 0.0005 0.0005 -o india01.osm
srtm2osm.exe -bounds1 15 68 22.4 89.5 step 20 -cat 500 100 -large -corrxy 0.0005 0.0005 -o india02.osm
osmconvert india01.osm -v=2 -B=ml-india01.poly >india01-c.osm
osmconvert india02.osm -v=2 -B=ml-india02.poly >india02-c.osm
java -Xmx2000m -jar splitter.jar --cache=cache --mixed --output=xml --geonames-file=cities15000.zip --mapid=632400xx india01-c.osm
java -Xmx2000m -jar splitter.jar --cache=cache --mixed --output=xml --geonames-file=cities15000.zip --mapid=632400xx india02-c.osm
java -Xmx2000m -jar mkgmap.jar --max-jobs=2 --latin1 --keep-going --transparent --style-file=style --style=ml-cont --tdbfile --family-id=20028 --product-id=1 --description=in-cont3 --series-name=in-cont3 --family-name=in-cont3 --overview-mapname=in-20028 -c template.args
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?
es sind keinerlei relationen enthalten. ausschleißlich ways, alle mit “contour=elevation” getaggt.
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.
die poly’s sind selbergemacht
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…?
nix vertraulich 
ich mach die poly mit einem selbst geschriebenen tool, und hatte noch nie probleme.
es sind “normale” vielecke, ohne extreme ausreisser, und auch ohne überlagerungen, ausschnitte oder ähnliches.
india03
1
73.870233334600925 15.000000027939677
80.142433354631066 15.000000027939677
80.28097883798182 14.572787247598171
80.225050169974566 14.177528461441398
80.353357074782252 13.788557946681976
80.322651145979762 13.658302249386907
80.45424803160131 13.336705304682255
80.348970573395491 12.905513970181346
80.245886323973536 12.44647485204041
79.981595948338509 12.063792524859309
79.851095750927925 11.588583709672093
79.925667280331254 11.381971221417189
79.946503518149257 10.911254016682506
79.951986707746983 10.582470595836639
79.977209446951747 10.243805749341846
79.894961351528764 10.187211893498898
79.474948039278388 10.247398987412453
79.343351237475872 10.155770787969232
79.369670581072569 10.052464585751295
79.017649004235864 9.561984362080693
79.068094482645392 9.390406217426062
79.389410130679607 9.394897744059563
79.578032288700342 9.166725659742951
79.435469023883343 9.05263957567513
79.057128103449941 9.13169139996171
78.972686799243093 9.182895356789231
78.36514818482101 8.975384496152401
78.283996777608991 8.888247907161713
78.220391627401114 8.439090214669704
78.104147789999843 8.302546329796314
77.57776066660881 8.003407353535295
77.333209840580821 8.029458476230502
77.068919464945793 8.186663668602705
76.908809943124652 8.350157048553228
76.509633203968406 8.828060813248158
76.391195990145206 9.094860395416617
76.225603278726339 9.464966347441077
76.180640989914536 9.779376648366451
76.077556824311614 10.142296124249697
75.963506195694208 10.45041823759675
75.80778325907886 10.811540968716145
75.701409112662077 11.213986231014132
75.558846015483141 11.440361738204956
75.437118904665112 11.693686656653881
75.204631313681602 11.910180654376745
75.142122767865658 11.941621676087379
74.983109934255481 12.30993096716702
74.737462420016527 12.835445366799831
74.688113629817963 13.034871378913522
74.595995927229524 13.377129547297955
74.542260551825166 13.724777530878782
74.41066375002265 14.008645182475448
74.298806414008141 14.406598834320903
74.094831459224224 14.68866990879178
73.870233334600925 15.000000027939677
END
END
india04
1
73.870233334600925 15.000000027939677
80.142433354631066 15.000000027939677
80.157335205003619 15.159836299717426
80.247259698808193 15.375432008877397
80.324024520814419 15.581146208569407
80.466587785631418 15.732961418107152
80.617924137040973 15.80572497099638
80.704558733850718 15.812013242393732
80.736361350864172 15.687147360295057
80.849315291270614 15.641333302482963
80.998458433896303 15.654808050021529
81.114702103659511 15.769792422652245
81.096059158444405 15.823691328987479
81.234235921874642 15.938675701618195
81.289067901670933 16.162356175482273
81.354866344481707 16.246797814965248
81.450274027884007 16.283628735691309
81.564324656501412 16.284527108073235
81.706887921318412 16.242306288331747
81.884543364867568 16.296205194666982
82.166379913687706 16.421969281509519
82.407640842720866 16.549530113115907
82.432863581925631 16.689667236059904
82.439443459734321 16.954670324921608
82.419703910127282 17.045400151982903
82.585296621546149 17.182842409238219
82.7859818469733 17.298725070431828
83.09194453060627 17.440658854320645
83.299209214746952 17.552049988880754
83.42422622255981 17.676017498597503
83.538276851177216 17.861968763172626
83.668777048587799 17.97874971292913
83.877138756215572 18.100920645520091
84.226966788992286 18.269803924486041
84.235739959403872 18.322804542258382
84.421072220429778 18.461145088076591
84.495643749833107 18.581519359722733
84.675492737442255 18.798911646008492
84.830118902027607 19.00013423524797
84.907980328425765 19.139373153448105
85.099892467260361 19.285798547789454
85.303867589682341 19.460970014333725
85.598863642662764 19.619073495268822
85.888376673683524 19.72866796888411
86.219562096521258 19.819397795945406
86.429020408540964 19.901144485920668
86.522234883159399 19.991874396800995
86.597902849316597 20.137401418760419
86.911542015150189 20.299996510148048
86.849033553153276 20.43654047884047
87.179122287780046 20.700645195320249
86.955407615751028 21.107581984251738
86.93895804695785 21.186633724719286
87.096874276176095 21.401331061497331
87.383097410202026 21.473196325823665
87.609005374833941 21.56572281382978
87.909210361540318 21.658249301835895
88.086866140365601 21.485772784799337
88.325933776795864 21.487569361925125
88.528812043368816 21.563027864322066
88.705371133983135 21.499247532337904
88.999999975785613 21.552249994128942
88.999999975785613 22.000000029802322
69.057900002226233 22.000000029802322
69.521565260365605 21.589528257027268
69.829720901325345 21.269727973267436
70.038082525134087 21.052335686981678
70.25302411057055 20.889740595594049
70.51841109059751 20.737027013674378
70.778314881026745 20.637314049527049
70.953777367249131 20.623839301988482
71.259739715605974 20.715467417612672
71.532803177833557 20.83494340069592
71.745551386848092 20.946334451436996
72.062480533495545 21.091861557215452
72.232459662482142 21.18079480715096
72.507716417312622 21.179896434769034
72.559258500114083 21.030776090919971
72.643699804320931 20.974182235077024
72.79613284394145 20.615754453465343
72.69414528273046 20.341768311336637
72.589964428916574 20.018374789506197
72.584481239318848 19.782117856666446
72.652472890913486 19.509928291663527
72.683178819715977 19.261094983667135
72.742397468537092 19.066160498186946
72.693048594519496 18.898175591602921
72.785166380926967 18.8065473921597
72.772006709128618 18.634070875123143
72.82683877274394 18.386135855689645
72.886057086288929 18.105861442163587
73.017653888091445 17.735755573958158
73.030813643708825 17.630652710795403
73.111964967101812 17.330615362152457
73.17557011730969 17.063815696164966
73.204082837328315 16.767371669411659
73.239175267517567 16.49697876535356
73.35212929174304 16.11249977722764
73.421217631548643 15.897802440449595
73.504562331363559 15.866361418738961
73.630675943568349 15.611239839345217
73.690991029143333 15.455831307917833
73.719503665342927 15.322880577296019
73.802848365157843 15.29233792796731
73.870233334600925 15.000000027939677
END
END
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.
32-bit problem ?
ich denke nicht. unter win ja, ist aber unter linux geschnitten, damit eher nicht
ich glaub ich hab’s:
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.
Danke für die Analyse!!
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:
./osmconvert x.osm -o=x.o5m
Moin moin,
nur ein kleiner Hinweis:
osmconvert schneidet nach 7 Nachkommstellen ab und löscht auch den space vor dem abschließenden ‘/>’
Schon deshalb sind die output-Dateien von osmconvert kleiner als von Srtm2Osm
die noderefs sind weg, ich hab’s mit einem texteditor kontrolliert. ich poste mal ein stück quelltext und beispiel-dateien, wird aber erst heut abend.
So, mal probiert
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
Ciao,
Frank
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)
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)