Das ist eine Gute Frage.
http://m.m.i24.cc/osmconvert_new.exe ist 0.5F
und
http://m.m.i24.cc/osmconvert.exe ist noch 0.4N
Da müssen wir wohl auf Markus warten.
Sorry, ich hab verbummelt, dass ihr das für Windows übersetzt braucht.
0.5J ist grad neu oben - mit noch etwas mehr Infoausgaben.
Das Problem mit den > 2GB Dateinen besteht noch! Zumindesten bei meiner europe.pbf (ca. 5,7 GB)
osmconvert-05J.exe -v=2 --drop-version --drop-author --emulate-osmosis --out-pbf -b=8.7,49.75,9.75,50.5 G:\PBF\europe.osm.pbf > G:\PBF\Test-05J.pbf
Läuft ohne Probleme
osmconvert-05J.exe -v=2 --complete-ways --drop-version --drop-author --emulate-osmosis --out-pbf -b=8.7,49.75,9.75,50.5 G:\PBF\europe.osm.pbf > G:\PBF\Test-05Jcom.pbf
osmconvert-05J.exe -v=2 --complex-ways --drop-version --drop-author --emulate-osmosis --out-pbf -b=8.7,49.75,9.75,50.5 G:\PBF\europe.osm.pbf > G:\PBF\Test-05Jplex.pbf
Bricht mit Fehlermeldung ab
complex mit could not jump in file : G:\PBF\europe.osm.pbf … last processed : relation 1845254
complete mit could not rewind file: G:\PBF\europe.osm.pbf … Next byte to parse : 00 00 00 0E 07 4F 53 …last process relation 11
kann das leider nur bestätigen, srtm-daten mit ca 2,5 gb:
E:\daten\osmconvert>osmconvert5j test2.osm -v=2 -B=test.poly --complete-ways 1>
test2-c.osm
osmconvert Parameter: -B=test.poly
- 0 865655385,279600165,888849331,279168973
- 1 861970673,263160995,865655385,279600165
- 2 861970673,263160995,881381210,263080146
- 3 878815071,270033107,881381210,263080146
- 4 878815071,270033107,888849331,279168973
Border polygons: 5. Now sorting.
0 861970673,263160995,865655385,279600165
- add to chain of 1
- add to chain of 2
1 861970673,263160995,881381210,263080146
- add to chain of 0
- add to chain of 2
- add to chain of 3
- add to chain of 4
2 865655385,279600165,888849331,279168973
- add to chain of 3
- add to chain of 4
3 878815071,270033107,888849331,279168973
- add to chain of 4
4 878815071,270033107,881381210,263080146
- add to chain of 3
Chains:
0 861970673,263160995,865655385,279600165
1 861970673,263160995,881381210,263080146
1 861970673,263160995,881381210,263080146
0 861970673,263160995,865655385,279600165
2 865655385,279600165,888849331,279168973
0 861970673,263160995,865655385,279600165
1 861970673,263160995,881381210,263080146
3 878815071,270033107,888849331,279168973
1 861970673,263160995,881381210,263080146
2 865655385,279600165,888849331,279168973
4 878815071,270033107,881381210,263080146
4 878815071,270033107,881381210,263080146
1 861970673,263160995,881381210,263080146
2 865655385,279600165,888849331,279168973
3 878815071,270033107,888849331,279168973
End of border initialization.
osmconvert Parameter: --complete-ways
osmconvert: zlib 1.2.5 flags: 00000055
Write-opening: stdout
Tempfiles: osmconvert_tempfile.3416.*
osmconvert: changing dependencystage from 0 to 21.
osmconvert Warning: wrong sequence at way 1000000000
osmconvert Warning: next object is node 1000000005
osmconvert Warning: wrong sequence at way 1000000001
osmconvert Warning: next object is node 1000000022
osmconvert Warning: wrong sequence at way 1000000002
osmconvert Warning: next object is node 1000000029
osmconvert Error: could not rewind file: test2.osm
osmconvert: Last processed: way 1000480901.
osmconvert Exit: 28
Read-closing: test2.osm
Ja, das ist schade, denn 55 (hex) ist 01010101
und somit size of z_off_t
01
und somit 32 Bit
Ich hab’ auf meiner (64 Bit Debian 6, -O3) Schüssel
osmconvert: zlib 1.2.3.4 flags: 000000a9
a9 ist 10101001 und somit size of z_off_t
10
und somit 64 Bit
Falls ich das jetzt richtig verstanden haben 
EDIT:
Nein, doch nicht richtig verstanden:
mit “-m32” (32 Bit) kompiliert, dann erhalt ich
osmconvert: zlib 1.2.3.4 flags: 00000055
es geht aber trozdem mit > 2 GB
Es wird wohl nicht wirklich die 2 GB größe sein sondern eher die Anzahl Nodes, ID’s oder sonstwelche Werte die da irgendwas zum Überlaufen bringen!
Ohne complete + complex wird wohl das nicht so beansprucht - läuft ja durch und ergibt genau das selbe wie die 04N .
OSM-srtm-daten sind da noch ein Spezialfall weil diese sehr viel Nodes und dazu noch einer Art haben.
mkgmap und Co haben damit auch ihre Probleme - da passen z.B die Höhenlinien (10m Stufen) von D nicht in eine IMG und muß aufgeteilt werden da die maxzahl an nodes in der IMG überschritten wird.
Ja, ich hab auch erst gedacht, dass 0x55 bedeutet, dass die Sprünge mit 32-Bit-Datei-Offsets möglich sind. Auf meiner 32-Bit-Linux-Kiste gibts aber auch mit größeren Dateien keine Probleme (z.B. europe.pbf). Anscheinend stellt sich da Win32 quer, denn die zlib unterstüzt sowas - insbesondre die neue zlib-Version 1.2.5.
Rätselhaft. Da bleibt bei Win32 wohl nur der Ausweg, zuerst einen größeren Bereich aus der europe.pbf ohne --complex-ways auszuschneiden und dann den kleineren Bereich mit --complex-ways aus dem größeren auszuschneiden.
EDIT:
Hab grad eine Testversion hochgeladen: m.m.i24.cc/osmconvert_new2.exe
Diese Version kann keine zlib-komprimierten Dateien lesen, aber viellllleicht innerhalb von großen Dateien springen…
Für die, die es interessiert, verantwortlich ist die Einstellung “read_GZ” in der Quelldatei (Zeile 1433).
Mit der 05.J+ ist immer noch das Problem mit der europe.pbf.
Großräumig ausschneiden (z.B. germany als bbox) und daraus dann den Ausschnitt mit “–complex-ways” geht.
Bei der 05.J und der Plus-version bekomme ich bei -v=2 die Meldung:
osmconvert : Not a standrad .o5m File header osmconvert_tempfile.3560.1
vielleicht hilft das !
Danke, aber die Warnung wegen dem Header ist normal. Das Programm verwendet intern ein vereinfachtes .o5m-Format für temporäre Dateien.
Aber mir kam vorhin noch eine andere Idee: ich hab statt des Funktionsnamens gzseek() spaßhalber gzseek64() eingegeben, und anscheinend gibt es diese Funktion. In der zlib-Doku habe ich sie nicht gefunden.
Könnte jetzt das Problem lösen: Version 0.5K m.m.i24.cc/osmconvert_new.c bzw. m.m.i24.cc/osmconvert_new3.exe
Danke für eure Geduld! Mit Win32 ist es nicht immer einfach… 
Grins
Ist doch eher umgedreht - Danke für die Geduld und die Arbeit die du für “uns” verbrauchst!
Leider ändert sich nix mit der 05K.
bei der europe.pbf und konvertiert in o5m probiert!
Ich kann mit der Lösung über einen Ausschnitt zu gehen um --complex-ways verwenden zu können leben.
Klar wenn man Frankreich aus der europe mit --complex-ways haben will wird das wohl nicht mehr so zu lösen sein - ist für mich aber nur Theoretischer Natur.
Solange 100-200km-Rand mehr gehen als Gebraucht dürften nur wirklich selten bis garnicht Probleme mit den MP’s noch auftreten!
Deshalb ist das für mich nicht mehr als so dringendes Problem anzusehen - wichtiger ist das --complex-ways so geht.
Es ist aber doch irgendwie der Hammer was du aus dem Rechner so rausholst!
Von der 04N version zu den 05-Versionen ist das ausschneiten nochmal 20% schneller geworden!!!
Hallo Ausschnittexperten,
da es jetzt mit MOBAC,OSMCONVERT und Maperitive einfach ist von grafisch ausgewählte Gebiete (BoundingBoxen) in Tiles zu rendern habe ich mal etwas gespielt. Ich war der “naiven” (?) Meinung, dass wenn man mehrer überlappende Gebiete rendert und diese wieder als Eingabe (Mapsource) für MOBAC verwendet dass man zu einer gesamten Karte kommt die “wächst”. Das ist aber nicht so. Je nachdem was ich zuletzt rendere entstehen da weiße Flecken und die Gesamatkarte ist unbrauchbar. Die einzelnen Gebiete sin für sich gesehen ok, bis das oben viel diskutierte Randproblem. Ich hätte jetzt erwartet, dass eine Gesamtkarte aus einzelnen Gebieten bis euf die unschönen Randerscheinungen der einzelnen Gebiete eine einigermaßen brachbare Gesamtkarte rauskommt.
Ich habe da aber noch nicht eingehender untersucht. Kommt das jetz vom ausschneiden (osmconvert) oder vom rendern (Maperitive) ? Kann mir da jemand ne Erklärung/Tipp geben. Ich werde das aber noch weiter untersuchen.
MfG
Achim
Ps: Schreckliche Gesamtmap ==> http://augilabs.de/osm/bild/Schnitzel.png (oben rechts in der Menüleiste das “neu” Toolmenü mit dem ich osmconvert aufrufe)
Das mit Maperitive mache ich noch interaktiv.
Leider keine Veränderung mit der 0.5K und den SRTM-Daten, allerdings grade nur auf Win XP 32bit, 700MB Ram getestet. 64bit-Test geht erst morgen Nachmittag.
Und ich möchte mich quasilotte anschließen: danke für das Tool. Selbst wenn --complete-ways für große Dateien nicht hinzukriegen sein sollte, wäre ich sehr dafür, die Funktion trotzdem zu behalten. Ich schneide lieber kleine Kacheln sauber, als große mit Osmosis zu bearbeiten zu müssen und auf complete-ways zu verzichten.
Mit ist außerdem grad noch ne Idee gekommen, die mir höchstwahrscheinlich weiterhelfen wird (und vielleicht ja auch anderen): mein Workflow momentan ist srtm2osm → osmconvert → mkgmap splitter → mkgmap, und ich muss halt aufpassen, dass srtm2osm keine zu großen Kacheln generiert.
Ich werde morgen mal folgendes testen: srtm2osm → mkgmap splitter → osmconvert → mkgmap. Alle Kacheln, die der Spiltter ausspuckt, sind definitiv klein genug für osmconvert. mal sehen, wie’s klappt.
Also das Bild sieht mir eher so aus als ob Maperative eine größere Boundingbox nimmt und so die fertigen Kacheln mit Daten durch solche ersetzt, welche keine Daten enthalten.
Ein Ausweg könnte vielleicht sein, die Kacheln in ein neues Verzeichnis zu rendern, und nur die “guten” zu übernehmen. Ajoessen hatte zum Beispiel ein Skript, welches vor dem Upload auf den Server alle leeren Kacheln löscht. Allerdings wird es dann zu Problemen mit “halbvollen” Kacheln kommen, so dass du wahrscheinlich nicht um das geschickte aussortieren von relevanten Kacheln zu jeder Boundingbox herumkommst.
Also nur Kacheln, welche vollständig in der ausgeschnittenen Boundingbox liegen. Diese übernimmst du dann in dein Verzeichnis, welches du an Mobac verfütterst.
Hi
die Antwort ist naheliegend und auch Richtig! Es kann doch aber nicht sein, dass jeder anfängt irgendwie ne Frickellösung zu basteln. Die Tiles zu untersuchen ist sicherlich kein gangbarer Weg. Was ist leer? Klar 2KB (?) oder halb leer oder Viertel leer…usw.
Wenn man Tiles nicht eindeutig als ok (plausibel) erkennen kann ist das Verfahren zusammenkopieren zum Scheitern verurteilt.
Es soll ja ne Lösung rauskommen, mit der man ohne großen Kenntnisse Kartentiles generieren kann und dass eine Gesamtkarte mit der Zeit wächst.
Eventuell werde ich eher den Maperitive Autor befragen ob er nicht im Sinne der OSM-Tilesgrenzen nur vollständige Tiles generiert. Dort müssten doch die Grenzen der Tiles sowieso bestimmt werden . Es gibt ja auch ein Geometry Bound Feature in Maperitive. Aber das kann ich wohl nicht (Tile)rastermäßig setzen. Man sollte so weit vorne eingreifen wie möglich.
Aber ich bleibe da dran. Ziel ist mit einem Klick in MOBAC gebiete zu erstellen, die sich zu einer Gasamtkarte zusammenfügen…
MfG
Achim
Ps: Ich werde mal versuchen ganze Tile Grenzen (Kachel) in Mobac zu selektieren und diese Boundinggrenzen in Maperive genauso GeometryBounds setzen Schaun mer mal was das bringt…
Es geht mir nicht darum, dass jeder seine frickellösung findet.
Ajoessen hat schlicht alle Kacheln verworfen, welche diese 2 Kb hatten. Also keine Daten enthielten. Mehr wurde da nicht geprüft.
Auch Maperative ist kaum in der Lage zu entscheiden, welche Kachel jetzt vollständig ist und welche nicht.
Als gangbaren Weg sehe ich eigentlich nur den Weg von Openlayers, welche zur aktuellen Boundingbox die bnötigten Kacheln lädt. Wenn du das Verfahren umdrehst und nur die vollständig in der Boundingbox eingeschlossenen Kacheln übernimmst, dann hast du dein Ziel denke ich erreicht. Es ist nur eben nicht soeinfach zu berechnen, welche Kacheln in der Box liegen und welche von dieser geschnitten werden. Gerade bei gorßen Kacheln könnte es zu Problemen führen.
Aber vielleicht kann dir der Autor von Maperative da mit einer Option helfen, dass nur Kacheln innerhalb der Boundingbox berechnet werden oder wenigstens die anderen nicht gespeichert werden.
Schade, dabei hatte ich letzte Nacht wirklich Hoffnung…
Dann bleibt eben vorerst diese Einschränkung im Fall von Win32. Unter Umständen löst sich das Problem, wenn jemand direkt unter Win32 das Programm mit MinGW übersetzt. Man könnte aber auch CygWIN verwenden. Ist beides natürlich nur eine Notlösung, aber vielleicht klappts.
Gibts eigentlich sonst noch Probleme mit der 0.5K? Falls nicht, dann würde ich sie als offizielle Version auf den Server schieben.
Schöne Grüße
Markus
Der Versuch des direkten Übersetzens scheiterte leider bei mir kläglich.
Hi
nochmals zu meinem Problem einer Gesamtkarte aus mehreren Teilgebieten. Das Problem ist lösbar, wenn man in Maperitive die gleichen Boundgrenzen setzt wie in MOBAC. Ich muß das nur noch automatisieren. Aber sieht jetzt schon mal astrein aus. Das Ganze muß ich nur noch automatisieren…
MfG
Achim
Ps: Ich mache da eventuell einen neuen Thread auf “Mobac/Osconvert/Maperitive/Mobac-Kettenverarbeitung”
In Maperitive kann ich ja keine großen Gebiete rendern wegen dem Memoryüberlauf. Ich möchte aber Zoomlevel 6-12 trotzdem rendern können (Windows 32 Bit) meine Idee ist nun den File zB: Baden-Württemberg.bpf für diese Zoomlevel so auszudünnen das man das rendern kann. Da Brauche ich ja keine Highway=track etc. Macht man das mit osmconvert oder osmfilter. Ideal wäre natürlich man browsed die RULES von Maperitive Levelabhängig und schneidet dann entsprechen aus.
Wie der Name schon sagt ist osmfilter, dass Programm zum filtern.
Und wenn du später noch langeweile hättest könntest du das Extract vor der Verarbeitung noch updaten. Dafür gibts osmupdate. Allerdings setzt das unter Windows noch wget vorraus, bevor du daran scheiterst. Und unter Windows7 möchte das Programm nicht Update im Namen führen, da sonst Adminrechte nötig werden. Aber das ist nur für die Langeweile später!
Ansonsten finde ich das echt klasse, dass du eine einfache Lösung findest. Das browsen der Ruels ist wahrscheinlich eher eine Sache, welche man dann nicht mehr mit einem einfachen Batch auruf gestalten kann. Da sollte man dann vielleicht doch wieder zu einer Hochsprache greifen.
Hi
ich schalte sowieso noch ein eigenes C# Programm dazwischen, in dem ich die Optionen zB. für osmconvert via Häckchen setzen kann. Das mit den Batchfiles ist nur ne Zwischenlösung…
MfG
Achim
Ps:
Stand vorher: http://augilabs.de/osm/bild/Schnitzel.png
Stand aktuell: http://augilabs.de/osm/bild/Schnitzel_01.png …so in etwa stelle ich mir eine “wachsende” loakale Karte vor jedoch einfach ein “rotes” Kreuz (nicht vorhanden) selektieren und dann unter Tools==>generieren…
Scheint also machbar zu sein! So komme ich mit meinem nur 32 Bit System auch zu großen Karten…
die Schnittstellen der einzelne Teilkarten sin astrein ==> http://augilabs.de/osm/bild/Schnitzel_03.png
