Aktuell bin ich bei der händisch-eintippen-Variante.
Aber noch nicht bei Osmosis sondern bei ** pbftoosm **.
**Und da läuft irgendetwas schief. **
Folgendes habe ich gemacht:
Verzeichnis aufgerufen, in dem pbftoosm und germany.osm.pbf stehen
Kommandozeile zum Erstellen einer Bounding-Box eingegeben
pbftoosm <germany.osm.pbf -b=6.75,51.15,7.5,51.8 >Essen.osm
Ergebnis: eine Datei mit 1.957 KB
Da sie ohne den Befehl --drop-brokenrefs erstellt wurde, kann Composer die aber nicht verarbeiten.
Außerdem möchte ich die history rauswerfen.
Daher wiederhole ich die Berechnung mit folgender Befehlseingabe:
pbftoosm <germany.osm.pbf -b=6.75,51.15,7.5,51.8 --drop-brokenrefs --drop-history >Essen.osm
Ergebnis: im Explorer wird eine Datei mit 442.954 KB angezeigt.
Diese Datei ließ ich mit Composer berechnen.
Zuerst sah alles normal aus. Doch am Ende konnte mkgmap keine *.img etc. erstellen.
Mich wunderte, daß die 2. Datei größer war, als die erste.
Ich hab erwartet, daß es genau umgekehrt ist.
Aus purer Neugier erstellte ich noch einmal denselben Exptrakt ohne --drop-xxx
Die nun erzeugte Datei war mit 837.102KB deutlich größer als die erste. - - - ???
An der hat Composer sich logischerweise aufgehängt.
Und nun?
Gruß
tippeltappel
EDIT
5. Ich habe noch einen Testlauf gemacht und dabei --drop-history weggelassen:
pbftoosm <germany.osm.pbf -b=6.75,51.15,7.5,51.8 --drop-brokenrefs >Essen.osm
Ergebnis: im Explorer wird eine Datei mit 831.197KB angezeigt.
Das paßt zu dem Wert unter Punkt 4.
Composer hat aus dieser Datei wieder alle Datenberechnungen erstellt.
Nur mkgmap stürzte am Ende ab.
Eine der beiden *.img hat 0KB
die andere 16.747 KB
Die Typdatei hat die Größe von 283KB.
Die *.tbl fehlt.
klingt echt seltsam. Vielleicht ist die Programmdatei defekt? Welches Windows nutzt du eigentlich? 32- oder 64-Bit? Das Programm ist auf einem 32-Bit-System übersetzt worden, sollte aber eigentlich auch auf 64 Bit laufen. Eigentlich. Normalerweise Kann Windows das.
bring lieber osmosis endlich zum laufen.
osmosis ist DIE datenschleuder bei osm und somit das einzige programm in dem umfeld, dem ich 100% vertraue.
Alle wichtigen Sachen mit osm-daten laufen durch osmosis.
pbftoosm macht osmosis mit links(*). besonders wenn man weiss, das das pbf-format vom osmosis-entwickler selber definiert und eingebaut worden ist.
näher am entwickler kann man da nicht dran sein.
mag sein, dass pbftoosm schneller ist, aber wenn du deine arbeitszeit dazurechnest, hast du zeit verloren.
Meine Tests mit Win7-64 und WinXP-32 brachten das gleiche Ergebnis:
Die mit MinGW übersetzte Version erzeugt einen Output, der nicht ok ist. Ich bin mir nicht sicher, aber vielleicht handelt es sich sogar um einen Compilerfehler. Exakt der gleiche Quellcode läuft unter Linux ohne Probleme.
Ja, bei mir ist das Ergebnis auch wieder wie eben.
Da ist was faul.
@ wambacher
Die Osmosis-Kommandos hab ich vorhin noch mal durchgelesen.
Aber im Moment bin ich wohl zu vernagelt, um zu erkennen, was ich da brauche und wie ich da vorgehen muß.
Das verschieb ich dann mal besser auf Morgen. Genauer gesagt Morgen Abend.
die Funktion “–drop-history” ist aber schon recht nett bei pbftoosm (geht - glaube ich - so nicht mit osmosis)
und “etwas schneller” ist bei mir ca. 10-fach (ich arbeite auch nur mit sehr kleinen Datenmengen).
Gute Nachricht: ich hab ihn umzingelt, diesen Fehler.
Scheint an der Implementierung des Qsort-Algorithmus zu liegen. Irgendwas läuft da komisch unter Windows.
Aaaber… ich weiß, wie ich das Programm frisieren kann, dass es damit klarkommt.
Hallo!
Leider wieder nichts.
Genauer gesagt:
Composer hechelt die Daten durch, legt diverse Dateien an,
ruft mkgmap auf und dann
mkgmap failed
Das Programm kriegt die *.img immer noch nicht hin.
Schau dir doch die osmdatei vorher mal im josm an oder in einem Texteditor. Dann weißt du, ob die schon fehlerhaft ist, oder ob der Fehler sich erst im Composer eintritt.
da ist man am Wochenende offline, und schon rauchen eure Köpfe wg. osmosis
Unter Windows arbeite ich bei kommandozeilenprogrammen am liebsten mit “Open Comand Window Here”,
was es für Windows XP von Microsoft gibt: http://windows.microsoft.com/en-US/windows/downloads/windows-xp
(Den Google-Link zu softtonic würde ich nicht nehmen!
Damit kann man überall auf seinen festplatten in einem Ordner ein Kommandofenster öffnen.
Die batch-Datetein lege ich dann erst an, wenn es mit der Kommandozeile funktioniert.
Der Speicherbedarf von osmosis ist arg unterschiedlich: Wenn man einfach nur eine rechteckige bb ausschneidet, kommt es ganz ohne temporäre Dateiene aus. Dann ist auch europa mit weniger als 1GB RAM drin.
Sobald man --used-node oder -complete-relation nimmt, muss alles zwischengespeichert werden.
Also sollte man zuerst grob die Region aus Europa ausfiltern:
D:\Karten\OpenStreetMap\osmosis\bin\osmosis.bat --read-pbf E:\europe.osm.pbf --bb left=5.0 right=9.5 bottom=49.5 top=52.5 --write-xml eu-nrwplus.osm
Ja, mir deucht, bei der Standard-WinXP-Installation war da so was…
Arbeitsplatz/rechte Maustaste auf E: /Eigenschaften/Freigabe und Sicherheit/Sicherheit
Erweitert / Berechtigungen für alle untergeordneten…
Am besten alles für alle zulassen.
Mit OpenCommandWindowHere sollte tt das aber auf jeder Platte zum Laufen kriegen.
Nö, solche Ansprüche stellt XP nicht. Ich würde erst mal mit nem Regbez-Extrakt probieren, das läuft schneller durch. Die Kommandozeile von tt will nach E:\ schreiben, und darf es wohl nicht.
EDIT:
Wobei mich wundert, dass er beim task 1-read-pbf scheitert. Da dürfte er doch höchstens temporäre Dateien schreiben.
Vielen Dank Euch für’s Mittüfteln.
Zum Basteln und Probieren hab ich erst heute Abend wieder Zeit.
Daher nur kurz eine Zwischenbemerkung.
Ich denke, die Entstehung der/des Fehler/s hängt mit dem Ausschneiden der BoundingBox zusammen.
Das einfache Umrechnen einer *.osm.pbf zu *.osm führte dagegen in einem zurückliegenden Testlauf zu einer Datei, die nicht nur Composer, sondern auch mkgmap geschluckt haben. (Testlauf: Niedersachsen umgewandelt > fertige Karte war ok)
Wenn ich Composer mit einer alten auf anderem Weg entstandenen Essen.osm füttere, wird die Karte auch anstandslos berechnet.
@ ajoessen
Ich arbeite mit windows7 (siehe Posting#1)
nicht XP
Um das Problem mit den Schreibrechten zu prüfen, muß ich mir heute Abend Hilfe erfragen.
Das Betriebssystem lerne ich gerade erst kennen und da sind noch einige Fragen offen.