osmosis - ein Buch mit sieben Siegeln

Hi,

doch hätte schon funktioniert, wenn Du zuvor in z. B.
“%USERPROFILE%\osmosis.bat”
die
%OSMOSIS_OPTIONS%
gesetzt hättest.

Andere Variante, die von fx99, eine bat schreiben, die wiederum selbst o. g. osmosis.bat aufruft (siehe post #31)

Dritte Variante:
Die schwarze “Dos-Box” aufmachen und osmosis-Befehl händisch eintippen.

Ciao,
Frank

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:

  1. Verzeichnis aufgerufen, in dem pbftoosm und germany.osm.pbf stehen

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

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

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

Woran könnte das liegen?

grübel

Hi,

mit Deinem “composer” kenn ich mich nicht aus :wink:
doch probier mal “-i=” statt “<”, denn

$ pbftoosm -B=hersbruck.poly --drop-brokenrefs --drop-history < mittelfranken.osm.pbf > heb_db_dh.osm
$ pbftoosm -B=hersbruck.poly --drop-brokenrefs < mittelfranken.osm.pbf > heb_db.osm
$ pbftoosm -B=hersbruck.poly < mittelfranken.osm.pbf > heb.osm

$ pbftoosm -B=hersbruck.poly --drop-brokenrefs --drop-history -i=mittelfranken.osm.pbf > heb_db_dh_i.osm
$ pbftoosm -B=hersbruck.poly --drop-brokenrefs -i=mittelfranken.osm.pbf > heb_db_i.osm
$ pbftoosm -B=hersbruck.poly -i=mittelfranken.osm.pbf > heb_i.osm

$ ls -sh heb*
2,5M heb_db_dh_i.osm 2,6M heb_db_dh.osm 4,6M heb_db_i.osm 4,7M heb_db.osm 5,1M heb_i.osm 5,2M heb.osm

Ciao,
Frank

Hallo tippeltappel,

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. :slight_smile:

Vorschlag:
Lösch die Programmdatei pbftoosm.exe und lad sie neu runter:
http://m.m.i24.cc/pbftoosm.exe

Nimm dann bitte dieses Kommando:

Ich werde genau das Gleiche probieren, und zwar mit einem 32- und einem 64-Bit-Windows.

Hallo Ihr Zwei
Habe gerade die pbftoosm.exe herunter geladen und probiere das jetzt aus.
Melde mich, sobald der Testlauf durch ist.

Ich arbeite mit 32-Bit
(siehe Post 1)

Gruß
tippeltappel

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.

gruss
walter

Dem schließ ich mich für heute auch an. :slight_smile:

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.

Vielen Dank für Eure Hilfe!
Gute Nacht.

tippeltappel

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

MinGW
Wie, benutzt keiner M$ Visual Studio mehr? :wink:

läuft unter Linux ohne Probleme
Aber hallo!

:slight_smile:

Ciao,
Frank

Was ist das genau? :wink:

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.

Melde mich wieder.

Hi
Hab doch noch was probiert.
Nach einer Vorlage von ajoessen habe ich eine Berechnung mit OSMOSIS ausprobiert.
Das hat aber nicht geklappt:

Viele Grüße
tippeltappel

So, einmal Nachtschicht, und ein Windows-spezifisches Problem ist beseitigt. :slight_smile:
pbftoosm Version 0.9:
http://m.m.i24.cc/pbftoosm.c
http://m.m.i24.cc/pbftoosm.exe

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.

Hallo tippeltappel und andere,

da ist man am Wochenende offline, und schon rauchen eure Köpfe wg. osmosis :wink:

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

und dann erst zum finetuning übergehen.

Gruß,
ajoessen

Hallo tippeltappel,

hast Du schon mal einen Blick in die commands.log vom Map Composer geworfen? Der Inhalt ist bisweilen recht aufschlussreich :wink:

Gruß, softcake

sieht doch ganz gut aus - für mich.

ich sehe derzeit nur eine Ursache:

du darfts auf deine Platte in dem aktuellen Verzeichnis nicht schreiben

(“unable to open file for writing” am ende des ersten bildes)

der befehl an sich ist ok und das umfeld (java…) scheint auch ok zu sein.

walter@wno-server:~/OSM/projekte/planet$ osmosis --rb duesseldorf.osm.pbf --bb left=6.75  right=7.5  bottom=51.10 top=51.8 --wx Essen.osm
23.05.2011 10:12:41 org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.39

23.05.2011 10:12:43 org.openstreetmap.osmosis.core.Osmosis run
INFO: Preparing pipeline.
23.05.2011 10:12:43 org.openstreetmap.osmosis.core.Osmosis run
INFO: Launching pipeline execution.
23.05.2011 10:12:43 org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline executing, waiting for completion.
23.05.2011 10:14:15 org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline complete.
23.05.2011 10:14:15 org.openstreetmap.osmosis.core.Osmosis run
INFO: Total execution time: 94544 milliseconds
walter@wno-server:~/OSM/projekte/planet$

eventuell musst du noch apostrophe um die bbox machen, aber das kann ich nicht checken, da unser haushalt windows-freie zone ist.

–wx “file=c:\temp\Essen.osm” oder --wx ‘file=c:\temp\Essen.osm’

wäre auch mal einen versuch wert

gruss
walter

edit: lass erst mal die bbox ganz weg. dann macht er einfach aus pbf ein osm und wir schlagen uns nicht mit den komischen leerzeichen rum.

osmosis --rb duesseldorf.osm.pbf --wx Essen.osm

aber denk an die Schreibrechte/Plattenplatz

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.

BTW:
Die aktuelle pbftoosm läft bei mir mit:


pbftoosm.exe -h=1000 < D:\Karten\osm\Geofabrik\Duesseldorf.osm.pbf > duesseldorf.osm

Ob der mkgmap das Ergebnis frisst, weiss ich nicht.
Aber vielleicht sollte für die Probleme mit pbftoosm ein eigener Beitrag aufgemacht werden.

Gruß,
ajoessen

Moin Moin

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.

Bis heute Abend

Viele Grüße
tippeltappel

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

Viele Grüße
tippeltappel