PBFtoOSM - Windows

Sockeye wrote:

Möglicherweise erbarmt sich ja jemand hier PBFtoOSM für Windows zu kompilieren und der Community die Binarys zur Verfügung zu stellen?

Hallo!
Von einem Profi weiß ich, dass man die Quelldatei relativ einfach mit MinGW übersetzen kann. Ich selber kanns leider nicht, habs jedenfalls noch nicht geschafft, das Programm unter Linux mit MinGW für Windows zu übersetzen. Aber wenn du selber MinGW installierst, sollte das klappen.
http://de.wikipedia.org/wiki/MinGW
http://komisar.gin.by/mingw/index.html (nimm die Version 4.6.0)

Oder es findet sich hier jemand, der sowas schon öfter gemacht hat...? Wär natürlich super. :-)

Was willst du damit erreichen?! Ich denke PBF-Dateien in das XML-Format überführen?
Das geht auch mit Osmosis
Ich nutze hauptsächlich Ubuntu und Mac OS, aber da eine osmosis.bat existiert, sollte es auch unter Windows laufen. Dazu die pbf-Datein in das /bin-Verzeichnis kopieren und über die Kommandozeile aufrufen:

osmosis.bat␣--rb␣input.osm.pbf␣--wx␣output.osm

input ist dann die pbf-Datei und output die xml-Datei.
Kann sein, dass er auch hier mit "omitmetadata=true" rummeckert, ich ignoriere das immer, denn am Ende geht's trotzdem.
Wenn es klappt, wäre eine positive Rückmeldung super.

pbftoosm ist/wäre aber deutlich schneller als osmosis 😉

Hallo Sockeye,

Sockeye wrote:

Hallo zusammen,

ich würde gerne PBFtoOSM unter Windows64 nutzen. Leider habe ich keinen blassen Schimmer von C++ und wie ich den Source Code kompilieren kann. Ich habe zwar Visual Studio 2008, aber da haut es mir nur Fehlermeldungen um die Ohren... :-(

Möglicherweise erbarmt sich ja jemand hier PBFtoOSM für Windows zu kompilieren und der Community die Binarys zur Verfügung zu stellen?

Viele Grüße,
Sockeye

Das fertige .exe-File (compilert unter WinXP 32-Bit) gibt es hier:
http://www.datafilehost.com/download-1f2ddb50.html 114.358 Bytes, md5sum 96d7221b5f616c063dc92a6d774a0d77

Falls es bei Dir nicht läuft, Du einem fremden .exe-File nicht traust (was imho durchaus vernünftig ist) oder Du es aber selbst compilieren möchtest hier die Kurzanleitung:

- Lade Dir die (meiner Meinung nach beste) MinGW-Distribution unter

http://nuwen.net/mingw.html -> "mingw-7.1.exe"

bzw. direkter Download-Link http://nuwen.net/files/mingw/mingw-7.1.exe

herunter.

- Das ist ein selbstentpackendes 7z-File, also doppelklicken und auspacken nach "C:\MinGW"

- Windows-Pfad um "C:\MinGW\bin" ergänzen wie unter http://nuwen.net/mingw.html#install beschrieben.
Für WinXP (deutsch) z.B. geht das so: Unter Start -> Systemsteuerung -> System -> Erweitert -> Umgebungsvaribalen -> Systemvariablen -> Path -> Bearbeiten, dann ;C:\MinGW\bin hinten anhängen (Achtung: Strichpunkt nicht vergessen!), -> OK -> OK -> OK

- neue DOS-Box öffen (Start -> Programme -> Zubehör -> Eingabeaufforderung)

- gepatchtes "pbftoosm.c" C-Source-File von http://www.datafilehost.com/download-137ca707.html und z.B. unter "C:\OSM" (oder einen Pfad Deiner Wahl) speichern. (Das Original von http://wiki.openstreetmap.org/wiki/DE:P … nformation -> "Quellcode" funktioniert ungepatched nicht unter Windows)

- In der DOS-Box

cd␣c:\OSM

bzw. "cd" zu dem Pfad zu "pbftoosm.c"

- Compilieren mit

gcc␣-c␣pbftoosm.c

- Linken mit

gcc␣-o␣pbftoosm␣pbftoosm.o␣-lz

Danach solltest Du ein "pbftoosm.exe" haben. 🙂

Bitte gib mir Rückmeldung, ob bei Dir unter Win7-64Bit mein fertiges Win32-exe läuft und ob das Selbst-Compilieren bei Dir geklappt hat.

Schöne Grüße

PA94

Na wenn man sich über Geschwindigkeit gedanken macht, sollte man nicht mit Windows arbeiten 😎
Ich kann ja mal einen Benchmarktest machen...

Hab gerade gesehen, dass es ja schon einen ausführlichen Benchmarktest gibt. Gibt es das ganze auch noch als osm2pbf? Oder muss man dann doch noch über osmosis gehen? Ist ja schön und gut, wenn man ein Polygon schnell ausschneiden kann, aber ich will es ja nicht (unbedingt) als xml-Datei haben.

Läuft bei mir prima unter 32bit-XP.

NRW (ohne weitere Filter) ist in 2 Minuten durch statt in 10.

Gruß und Dank,
ajoessen

railrun wrote:

Was willst du damit erreichen?! Ich denke PBF-Dateien in das XML-Format überführen?
Das geht auch mit Osmosis

Ich schneide regelmäßig bestimmte Bereiche aus dem Planet File heraus, welche weder von Geofabrik noch Cloudmade verfügbar sind. Osmosis ist hier schon lange im Einsatz, im wahrsten Sinne der Wortes :-) "waiting for execution..."

PA94 wrote:

Bitte gib mir Rückmeldung, ob bei Dir unter Win7-64Bit mein fertiges Win32-exe läuft und ob das Selbst-Compilieren bei Dir geklappt hat.

Ersteinmal vielen Dank für deine Mühe. Hier im Büro auf Win7 64 bekomme ich folgende Fehlermeldung:

Ich werde es zu hause nochmal versuchen, bzw den Anlauf starten es selbst zu Kompilieren. Mit deiner Anleitung klappt es bestimmt :-)

VG
Sockeye

ich hab hier ein pbf2osm.exe. Ist das was anderes?

Laut dem Benchmarktest aus http://forum.openstreetmap.org/viewtopi … 52#p162152 schon.

Nach Anleitung (oben) lies sich PBFtoOSM sofort kompilieren (Win7 64)

Nur leider scheint es Probleme mit großen *.pbf Dateien zu geben. So ab 120MB bricht er mit unterschiedlichsten Fehlermeldungen ab. Kleine Dateien macht das Programm einwandfrei.

Gibt es die gleichen Fehlermeldungen unter Linux?

VG
Sockeye

Sockeye wrote:

Nach Anleitung (oben) lies sich PBFtoOSM sofort kompilieren (Win7 64)

Nur leider scheint es Probleme mit großen *.pbf Dateien zu geben. So ab 120MB bricht er mit unterschiedlichsten Fehlermeldungen ab. Kleine Dateien macht das Programm einwandfrei.

Gibt es die gleichen Fehlermeldungen unter Linux?

VG
Sockeye

Linux kann ich grad nicht bieten, aber die aktuelle africa.osm.pbf läuft mit pbftoOsm auf XP 32bit ohne Murren durch, und erzeigt 3GB output. Liegt also wohl eher an den 64bit.

Gruß,
ajoessen

Hallo Sockeye,

Sockeye wrote:

Nach Anleitung (oben) lies sich PBFtoOSM sofort kompilieren (Win7 64)

Nur leider scheint es Probleme mit großen *.pbf Dateien zu geben. So ab 120MB bricht er mit unterschiedlichsten Fehlermeldungen ab. Kleine Dateien macht das Programm einwandfrei.

Gibt es die gleichen Fehlermeldungen unter Linux?

Mit der "africa.osm.pbf" vom 04.05. bekomme ich sowohl unter Linux als auch unter WinXP die Fehlermeldung wie Du auch

WinXP:

pbftoosm␣Error:␣way␣user␣string␣index␣overflow:␣41->4078064
pbftoosm:␣Number␣of␣bytes␣read:␣100866130

Linux:

pbftoosm␣Error:␣way␣user␣string␣index␣overflow:␣41->3086398973
pbftoosm:␣Number␣of␣bytes␣read:␣100866130

Sie unterscheiden sich also nur in der Zahl hinter "41->".

Mit dem zusätzlichen Parameter "--drop-his"

pbftoosm␣--drop-his␣␣<␣africa.osm.pbf␣>␣africa.osm

läuft es ohne Fehlermeldung durch.

Interessanterweise läuft auch die "africa.osm.pbf"vom 05.05. ohne "--drop-his" fehlerfrei durch.
Ich tippe daher auf einen kleinen Bug in "pbftoosm.c" in der History-Auswertung...

Schöne Grüße

PA94

Hier meine pbftoosm.exe (erstellt auf Win7-64):

http://www.datafilehost.com/download-e49d18dd.html

md5sum:
636e91fb9d158a46a6c63d1d3d23122f *pbftoosm.exe

Test mit africa.osm.pbf ok, Laufzeit: 59 sec.

Chris

PA94 wrote:

Ich tippe daher auf einen kleinen Bug in "pbftoosm.c" in der History-Auswertung...

Gut möglich. Aber ebenso möglich, dass beim Erstellen der .pbf-Datei ein Fehler passiert ist.
"way user string index overflow" bedeutet, dass ein String-Index enthalten ist, der größer ist als der Index des letzten Strings in der vorausgehenden Tabelle des Blocks. Ich hab einen solchen Fehler in der Datei schon einmal entdeckt, und zwar bei einem uid 0, also bei einem User-Namen, den es eigentlich nicht geben dürfte.

Aber falls ihr einen Programmfehler findet, wär das natürlich besser! :-)

Mit der Africa.osm.pbf vom 05.05. hat es einwandfrei funktioniert :-)
(41 Sec auf einem i7 920 auf SSD)
Die Europe.osm.pbf hat er auch gemacht in 26Min

Entweder war die Datei vom 04.05 korrupt oder beim Download hat es ein zwei Bits gedreht...

Vielen Dank jedenfalls an alle! Ich werde jetzt mal ein paar Benchmarks mit dem Planet.pbf fahren.

VG
Sockeye

Sockeye wrote:

Entweder war die Datei vom 04.05 korrupt oder beim Download hat es ein zwei Bits gedreht...

...oder das Programm hat noch einen Bug. :-)
Falls dir wieder mal eine PBF-Datei über den Weg läuft, die dir Probleme macht (am besten nicht eine so riesige wie planet.osm.pbf), dann poste bitte den Link auf den Download. Danke!

Hallo,

Marqqs wrote:

PA94 wrote:

Ich tippe daher auf einen kleinen Bug in "pbftoosm.c" in der History-Auswertung...

Gut möglich. Aber ebenso möglich, dass beim Erstellen der .pbf-Datei ein Fehler passiert ist.

Ja, stimmt. Aber mein Bauch sagt mir, daß es wahrscheinlicher ein Bug in "pbftoosm.c" ist 😉.

Marqqs wrote:

...oder das Programm hat noch einen Bug. :-)
Falls dir wieder mal eine PBF-Datei über den Weg läuft, die dir Probleme macht (am besten nicht eine so riesige wie planet.osm.pbf), dann poste bitte den Link auf den Download.

Besser: Schicke noch zusätzlich eine Mail an den Autor von "pbftoosm.c" Markus Weber (markus.weber § gmx.com <- absichtlich verfremdet als Harvester-Schutz).

Schöne Grüße

PA94

Ich muss zugeben, ich bin begeistert.. :-)

Deutschland aus der Europe.osm.pbf zu schneiden hat mit Osmosis 26:14 gedauert mit pbftoosm nur 9:16. Das ist fast Faktor 3

VG
Sockeye

mit nem gescheiden Rechner, gleiches Set-Up wie oben:
Osmosis: 00:13:40
Pbftoosm: 00:04:13

VG
Sockeye

Sockeye wrote:

mit nem gescheiden Rechner, gleiches Set-Up wie oben:
Osmosis: 00:13:40
Pbftoosm: 00:04:13

Danke fürs mitstoppen! :-)

Bei dieser Gelegenheit:

Die Version 0.4 von pbftoosm hat einen Bug. Wicking hat ihn in echter Kleinarbeit umzingelt (danke!), und ich hab ihn erlegt. Neu als Source gibt es nun die Version 0.5, die Binaries sind noch nicht upgedated.

Der Fehler ist allerdings in den meisten Fällen ohne Bedeutung. Zum Hintergrund:

Alle OSM-Objekte enthalten standardmäßig die History-Information: version, timestamp, changeset, uid, user.
Nun gab es in der Anfangszeit des OSM auch anonyme Edits. Dann entfallen die letzten beiden Elemente. Es bleiben: version, timestamp, changeset.

Die alte Version von pbftoosm kommt bei Relationen (nur bei Relationen) mit anonymen Edits nicht ganz klar und lässt version, timestamp und changeset dann ganz weg, wenn uid fehlt. Der Rest der jeweiligen Relation ist jedoch korrekt. Einige Programme stört das Weglassen dieser Infos nicht, manch andere melden einen Fehler.

Neues Programm osmconvert:

Ganz neu und bisher kaum getestet ist das Programm osmconvert. Es kann das Gleiche wie osmtopbf, ist jedoch ein kleines bisschen langsamer. ;-) Dafür können damit Changefiles verarbeitet werden. Das Programm unterscheidet sich in dieser Hinsicht nicht viel von dem einigermaßen bekannten osmchange, versteht aber zusätzlich die Formate .pbf und .o5m.

Kann osmconvert auch pbf+osc => pbf?

Ich seh gerade im wiki, dass er pbf nur lesen kann. Wäre cool, wenn er es auch schreiben könnte.

aighes wrote:

Kann osmconvert auch pbf+osc => pbf?

Ich seh gerade im wiki, dass er pbf nur lesen kann. Wäre cool, wenn er es auch schreiben könnte.

Stimmt, wär gut. Allerdings steckt recht viel Aufwand drin, einen Coder dafür zu programmieren, wenn man nicht die fertigen (und leider langsamen) Bibliotheken verwenden will.

Aber für welchen Zweck? Sowas wie hier?
http://wiki.openstreetmap.org/wiki/Dail … M_XML_file
Da wär das .o5m-Format letztlich eh besser geeignet als das PBF-Format.

Der Zweck wäre das updaten eines pbf-Planet. Die Ausgabe müsste pbf sein, da der splitter.jar (neben dem xml) nur pbf liest.

aighes wrote:

Der Zweck wäre das updaten eines pbf-Planet. Die Ausgabe müsste pbf sein, da der splitter.jar (neben dem xml) nur pbf liest.

OK, klingt logisch. Allerdings wärs da einfacher, dem Splitter .o5m beizubringen als dem osmconvert das .pbf-Schreiben. Mal schauen, wozu ich noch komme. Hoffentlich krieg ich das mit dem Filter bald auf dir Reihe.

Marqqs wrote:

Danke fürs mitstoppen! :-)

-)␣war␣nur␣ein␣Benchmark␣um␣meinen␣neuen␣i7␣2600k␣@4,8GHZ␣zu␣testen...

...wenn wir schon bei einen Wunschkozert sind...

- .pbf Ausgabeformat wäre SUPER
- das Ausschneiden mehrerer Boxen (analog der Osmosis --tee x Funktion)
- Multi-threading wäre das Sahnehäubchen. (bei meiner Konfig oben, war das Filesystem mit 90 MB/Sec nicht ausgelastet und die 7 restlichen Kerne gelangweilt.)

Bitte nicht falsch verstehen. Mit PbfToOsm ersparst du mir schon jetzt mehrere Stunden Zeit. Vielen Dank nochmal!

VG
Sockeye

Aber klar, wünschen darf jeder. :-)

Sockeye wrote:

- .pbf Ausgabeformat wäre SUPER

Ich hängs gern rein, wenn jemand das betreffende Code-Stück in C schreibt. Der Encoder ist leider einiges aufwändiger als der Decoder. Bis dahin bleibt nur, .o5m zu verwenden oder das Tool osm2pbf, um – leider über den .osm-Umweg – eine PBF-Datei zu erzeugen. Oder man nimmt gleich Osmosis. :-)

- das Ausschneiden mehrerer Boxen (analog der Osmosis --tee x Funktion)

Geht doch jetzt schon:
./pbftoosm -i=europe.pbf -B=germany.poly >germany.osm & ./pbftoosm -i=europe.pbf -B=austria.poly >austria.osm

OK, nicht direkt das, was du wolltest, aber wahrscheinlich trotzdem recht flott, weil in diesem Fall ja parallele Prozesse laufen.

- Multi-threading wäre das Sahnehäubchen. (bei meiner Konfig oben, war das Filesystem mit 90 MB/Sec nicht ausgelastet und die 7 restlichen Kerne gelangweilt.)

Siehe oben. ;-)
Aber du hast schon Recht, einen Teil des Algorithmus könnte man parallelisieren. Natürlich nicht alles, weil beim Ausschneiden von Extrakten vieles aufeinander aufbaut.

Hallo Marqqs,

PA94 wrote:

Ich tippe daher auf einen kleinen Bug in "pbftoosm.c" in der History-Auswertung...

PA94 wrote:

Marqqs wrote:

PA94 wrote:

Ich tippe daher auf einen kleinen Bug in "pbftoosm.c" in der History-Auswertung...

Gut möglich. Aber ebenso möglich, dass beim Erstellen der .pbf-Datei ein Fehler passiert ist.

Ja, stimmt. Aber mein Bauch sagt mir, daß es wahrscheinlicher ein Bug in "pbftoosm.c" ist 😉.

Marqqs wrote:

Bei dieser Gelegenheit:

Die Version 0.4 von pbftoosm hat einen Bug. Wicking hat ihn in echter Kleinarbeit umzingelt (danke!), und ich hab ihn erlegt. Neu als Source gibt es nun die Version 0.5, die Binaries sind noch nicht upgedated.

Der Fehler ist allerdings in den meisten Fällen ohne Bedeutung. Zum Hintergrund:

Alle OSM-Objekte enthalten standardmäßig die History-Information: version, timestamp, changeset, uid, user.
Nun gab es in der Anfangszeit des OSM auch anonyme Edits. Dann entfallen die letzten beiden Elemente. Es bleiben: version, timestamp, changeset.

Die alte Version von pbftoosm kommt bei Relationen (nur bei Relationen) mit anonymen Edits nicht ganz klar und lässt version, timestamp und changeset dann ganz weg, wenn uid fehlt. Der Rest der jeweiligen Relation ist jedoch korrekt. Einige Programme stört das Weglassen dieser Infos nicht, manch andere melden einen Fehler.

Und nun sagt mir mein Bauch: Ich habe die Wette gewonnen, Du schuldest mir ein Bier 😉 ...
Ich nehme ein dunkles Weizen...

Prost

PA94

PA94 wrote:

Und nun sagt mir mein Bauch: Ich habe die Wette gewonnen, Du schuldest mir ein Bier 😉 ...
Ich nehme ein dunkles Weizen...

Können wir gerne machen. Wo? :-)

Mit deiner Anleitung hab ich es übrigens geschafft, MinGW unter Wine zu installieren. Dort läuft die Compilierung durch, es gibt kein Gemecker wegen fehlender Bibliotheken. Ein Anfangsproblem hatte ich noch, denn das Exe lief unter Windows nicht korrekt, unter Wine schon. Und zwar unabhängig davon, ob ich es unter Wine oder unter echtem Windows übersetzt hab. Das Problem ist aber dank Mithilfe von fx99 gelöst.

Die neue Exe (Version 0.9) ist auch über die Wiki-Seite verlinkt:
http://wiki.openstreetmap.org/wiki/DE:Pbftoosm

Hi,

ich hab jetzt mal aus dem fred von Tippeltappel folgendes beispiel laufen lassen unter WinXP:

pbftoosm.exe␣-h=1000␣<␣D:\Karten\osm\Geofabrik\Duesseldorf.osm.pbf␣-b=6.75,51.45,6.85,51.5␣--drop-brokenrefs␣>␣bbox.osm

Durchlaufen tuts, und das Ergebnis ist so klein, dass es in josm gut reinpasst.

Dabei gibt es dann jede Menge Relationen mit 0 Elementen. Eben jene, deren Mitglieder ausserhalb der bb liegen.

Ist das ein bug oder ein Feature?

Eventuell hängt sich dann der Map Composer von nop oder mkgmap daran auf.

Gruß,
ajoessen

ajoessen wrote:

Hi,

ich hab jetzt mal aus dem fred von Tippeltappel folgendes beispiel laufen lassen unter WinXP:

pbftoosm.exe␣-h=1000␣<␣D:\Karten\osm\Geofabrik\Duesseldorf.osm.pbf␣-b=6.75,51.45,6.85,51.5␣--drop-brokenrefs␣>␣bbox.osm

Durchlaufen tuts, und das Ergebnis ist so klein, dass es in josm gut reinpasst.

Dabei gibt es dann jede Menge Relationen mit 0 Elementen. Eben jene, deren Mitglieder ausserhalb der bb liegen.

Ist das ein bug oder ein Feature?

Eventuell hängt sich dann der Map Composer von nop oder mkgmap daran auf.

Gruß,
ajoessen

Hallo ajoessen,

das ist weder Bug noch Feature, sondern ein technischer Nachteil wenn man weder Tempfiles noch Direktzugriff erlaubt. Weder Osmosis noch pbftoosm können zaubern. ;-) Das, was Osmosis mit Tempfiles erledigt, macht pbftoosm, indem es einen Teil der Eingabedatei mehrfach liest. Das geht aber nicht, wenn man sie über die Standardeingabe in das Programm reinschiebt, sondern man muss Direktzugriff auf eine vorhandene Datei erlauben. Siehe hier, im letzten Absatz des Kapitels:
http://wiki.openstreetmap.org/wiki/DE:P … en_Grenzen

Dein Kommando könnte dann so aussehen:

pbftoosm.exe␣-i=D:\Karten\osm\Geofabrik\Duesseldorf.osm.pbf␣-b=6.75,51.45,6.85,51.5␣--drop-brokenrefs␣>␣bbox.osm

Eine Weiterentwicklung des Programms pbftoosm, das recht neue osmconvert, verwendet statt des Direktzugriffs auch wieder temporäre Dateien. Ganz ohne technische Einschränkungen gehts also nicht - außer, man reserviert sich Unmengen an Hauptspeicher.
Da fällt mir auf, ich hab noch gar nicht geschaut, was pbftoosm genau braucht. Werd ich gleich mal machen.

Hallo zusammen

Nun trau ich mich doch mal hier herein.

Mit folgender Kommandozeile habe ich einen neuen Testlauf gemacht:

pbftoosm.exe -i=germany.osm.pbf -b=6.4,6.6,50.5,50.7 --drop-brokenrefs >Wolfgarten.osm

Der mit pbftoosm erzeugte planet-Ausschnitt wurde jetzt so verarbeitet, daß auch mkgmap am Ende Kartendateien erzeugen konnte.
Vordergründig sieht es so aus, als ob die Idee, vereinfachte Koordinaten einzugeben, zum Erfolg geführt hätte.
Da es sich aber um einen völlig anderen Kartenausschnitt handelt, kann es natürlich auch an etwas ganz anderem liegen.

Auch mit der Ergänzung --drop-history erzeugte Composer Kartendaten, aus denen mkgmap anschließend fehlerfrei eine Karte erzeugte.

Irritierend sind allerdings die Dateigrößen und die Berechnungsdauer.
Aus Niedersachsen.osm.pbf mit 85.107 KB errechnete pbftoosm Niedersachsen.osm mit 1.424.938 KB
Die aus germany.osm.pbf gezogenen Ausschnitte ergaben:
- Essen 830.932 KB (unbrauchbar)
- Wolfgarten.osm 7.654.591 KB (Composer und mkgmap fehlerfrei)
- Wolfgarten-h.osm 3.962.200 KB (ohne history - funktioniert ebenfalls - Berechnungsdauer 60 Minuten)
- Meine verschiedenen Wunschgebiete zu einer tippeltappel-polybox kombiniert und von jemanden, der es kann, vermutlich mit OSMOSIS aus dem Europafile ausgeschnitten, ist nur 4.922.895 KB groß (Berechnung mit Composer und mkgmap ca 50 Minuten - dabei sehr merkwürdig: Composer meldet einen mkgmap-Fehler, jedoch finde ich im Windows-Explorer Kartendaten, die sich mit MapsetToolkit problemlos installieren lassen und in MapSource angezeigt werden.
Obwohl das Gebiet von Wolfgarten nur einen winzigen Bruchteil von tippeltappel.osm darstellt, ist die Datei mit --drop-history nur etwa 1/5 kleiner.
Noch krasser: Der winzige Wolfgarten-Ausschnitt ist ca 5 mal so groß wie die Datei von ganz Niedersachsen.

Ich finde das alles sehr merkwürdig. Hinter die Kulissen gucken kann ich nicht. Das müßt Ihr machen.
Ich kann nur berichten, was mir auffällt.

Viele Grüße
tippeltappel

tippeltappel wrote:

Aus Niedersachsen.osm.pbf mit 85.107 KB errechnete pbftoosm Niedersachsen.osm mit 1.424.938 KB

Hallo und Willkommen hier drüben. ;-)
Der Faktor 85 MB zu 1,4 GB ist für .pbf/.osm realistisch.

tippeltappel wrote:

- Wolfgarten.osm 7.654.591 KB (Composer und mkgmap fehlerfrei)

7,6 GB für eine einzelne Gemeinde? Da stimmt etwas nicht. Sicher, dass du dich nicht um den Faktor 1000 verschaut hast?
Falls das wirklich korrekt ist, tippe ich auf ein defektes Polygon. Von der Größe der Datei her ist fast halb Deutschland mit eingeschlossen.
Magst du mir die Polygon-Datei mal schicken? Ich werds dann parallel hier probieren.

EDIT: Ich seh grad, du hast kein Polygon verwendet, sondern eine Box. Ich probiers aus.

tippeltappel wrote:

pbftoosm.exe -i=germany.osm.pbf -b=6.4,6.6,50.5,50.7 --drop-brokenrefs >Wolfgarten.osm

HALT, ich seh grad, du hast die Koordinaten vertauscht. Zuerst die südwestliche Ecke, dann die nordöstliche, also:

pbftoosm.exe␣-i=germany.osm.pbf␣-b=6.4,50.5,6.6,50.7␣--drop-brokenrefs␣>Wolfgarten.osm

Sonst schließt du halb Europa mit ein, kein Wunder, dass die Datei dann groß wird. ;-)

@Marqqs
Wenn ich mit '-wall -ansi -pedantic' bzw. '-c99' kompiliere, bekomme ich noch errors/warnings in der 0.9er.
Bekommst Du die noch weg, so dass sie immer noch fuer Linux und win laeuft?

Danke.

Ciao,
Frank

Marqqs wrote:

tippeltappel wrote:

pbftoosm.exe -i=germany.osm.pbf -b=6.4,6.6,50.5,50.7 --drop-brokenrefs >Wolfgarten.osm

HALT, ich seh grad, du hast die Koordinaten vertauscht. Zuerst die südwestliche Ecke, dann die nordöstliche, also:

pbftoosm.exe␣-i=germany.osm.pbf␣-b=6.4,50.5,6.6,50.7␣--drop-brokenrefs␣>Wolfgarten.osm

Sonst schließt du halb Europa mit ein, kein Wunder, dass die Datei dann groß wird. ;-)

Aaaah! Ich hatte mich schon selbst über die Reihenfolge der Koordinaten gewundert.
Die hatte ich von irgendwo (wo war das jetzt?) übernommen.
Somit dachte ich, das müsse so sein.

Ok, dann stelle ich das mal um.
Danke
tippeltappel

EDIT

🙂 Das war's!
Die Reihenfolge der Koordinaten hatte ich mit der Reihenfolge in der von ajoessen abgeschriebenen osmosis-Befehlskette verwechselt. Da werden die Koordinaten allerdings durch right= left= bottom= top= eindeutig gemacht.

Das Ausschneiden dauerte 1-2 Minuten,
die anschließende Verarbeitung mit Composer etwa 1 Minute.
Alles läuft sauber ohne Fehlermeldung durch.
Die Karte funktioniert in Mapsource.

Die Koordinateneingabe für Essen war Gestern richtig.
Allerdings hatte ich dort teilweise mehr als eine Nachkommastelle eingegeben.
Also Koordinaten auf 1 Nachkommastelle reduziert ..... > mkgmap failed

kellerma wrote:

Wenn ich mit '-wall -ansi -pedantic' bzw. '-c99' kompiliere, bekomme ich noch errors/warnings in der 0.9er.
Bekommst Du die noch weg, so dass sie immer noch fuer Linux und win laeuft?

Mit -Wall übersetze ich sowieso. Dafür hab ich schon extra den Code an einigen Stellen geändert, damit bestimmte Warnungen nicht erscheinen. - Obwohl der Code vorher völlig korrekt war! Mit -pedantic probier ich es lieber gar nicht. Ich mappe nicht für Renderer und ich programmiere nicht für "pedantische" Compiler. ;-)

Trotzdem, wenn du wirkliche Fehler oder Stellen entdeckst, die nicht gemäß C99-Standard sind, interessiert mich das natürlich! Immer her damit.

tippeltappel wrote:

🙂 Das war's!
Die Reihenfolge der Koordinaten hatte ich mit der Reihenfolge in der von ajoessen abgeschriebenen osmosis-Befehlskette verwechselt. Da werden die Koordinaten allerdings durch right= left= bottom= top= eindeutig gemacht.

Das Ausschneiden dauerte 1-2 Minuten,
die anschließende Verarbeitung mit Composer etwa 1 Minute.
Alles läuft sauber ohne Fehlermeldung durch.
Die Karte funktioniert in Mapsource.

Die Koordinateneingabe für Essen war Gestern richtig.
Allerdings hatte ich dort teilweise mehr als eine Nachkommastelle eingegeben.
Also Koordinaten auf 1 Nachkommastelle reduziert ..... > mkgmap failed

???????

Freut mich!

Das mit Essen versteh ich allerdings auch nicht. :-(

@Marqqs
Weitere Testkoordinaten, die funktionierten:
Siegerland: 7.4,50.5,8.2,51.2 --drop-brokenrefs

Diese dagegen funktionierten nicht: (Erweiterung um Essen)
Ruhrgebiet: 6.5,51.1,7.7,51.8 --drop-brokenrefs

Ich werde mir gleich mal ein neues germany.osm.pbf ziehen und weitere Gebiete testen.

@ Marqqs

Was bedeutet das?
Fehlermeldung von pbftoosm:

Reaktion von Composer:

Gruß
tippeltappel

Moin Moin 🙂

Anbei eine Grafik, die zeigt, wie ich das Fehlergebiet nach und nach eingegrenzt habe.
Da geht vielleicht noch mehr. Aber jetzt mach ich erst mal Schluß.

Für die Nicht-Composer-Kenner: Die Grafik wurde mit der Regionsübersicht in Nops Composer erstellt.

In diesem Bereich ist irgendetwas enthalten, das mir die Kartenberechnung des gesamten Gebietes runter gerissen hat, sobald es in einer Region enthalten war.
Beispiel Essen: Solange der Fehlerbereich im Kartenausschnitt enthalten war, funktionierte die Kartenerstellung nicht. Mkgmap erstellte eine von zwei *.img mit xyz KB und eine mit 0KB *.typ und *.tbl fehlten ganz. Als der Bereich ausgeklammert war, funktionierte die Erstellung der Essen-Karte.
Beispiel Ruhrgebiet (nicht abgebildet): Bevor ich die Zerlegung der Gebiete ausprobierte, dehnte ich die Essen-Karte auf das gesamte Ruhrgebiet + Soester Börde + Bergisches Land + Siegerland + Sauerland aus. Das ging schief.

Hier die Koordinaten:

Mit JOSM hab ich noch nicht versucht, das Fehlergebiet anzusehen.

Vielleicht mag ja jetzt jemand anderes das Gebiet genauer unter die Lupe nehmen.

P.S.
Es macht Spaß, wie flott pbftoosm die Daten ausschneidet.

Kann/Mag mir jemand erklären, wie man für pbftoosm eine eigene batchdatei schreibt, in der man mehrere Kartenausschnitte hintereinander zum Schneiden aufruft?

Eignet sich dafür der Notizblock aus Win-Zubehör ?
Wenn nicht, was dann?

Viele Grüße
tippeltappel

tippeltappel wrote:

Hier die Koordinaten:

Leider will abload.de die Bilder nicht rausrücken :-(

@marqqs:
Ist bei pbftoosm ausgeschlossen, dass Wege mit einem oder null Knoten in die Ausgabe gelangen?
Oder Multipolygone ohne outer?

Mit JOSM hab ich noch nicht versucht, das Fehlergebiet anzusehen.

Vielleicht mag ja jetzt jemand anderes das Gebiet genauer unter die Lupe nehmen.

P.S.
Es macht Spaß, wie flott pbftoosm die Daten ausschneidet.

Kann/Mag mir jemand erklären, wie man für pbftoosm eine eigene batchdatei schreibt, in der man mehrere Kartenausschnitte hintereinander zum Schneiden aufruft?

Eignet sich dafür der Notizblock aus Win-Zubehör ?
Wenn nicht, was dann?

Ich verwende dafür notepad++.

Im Prinzip müsste es doch so funktionieren:

pbftoosm.exe␣-h=1000␣<␣D:\Karten\osm\Geofabrik\Duesseldorf.osm.pbf␣-b=6.65,51.45,6.75,51.5␣--drop-brokenrefs␣>␣bbox1.osm
pbftoosm.exe␣-h=1000␣<␣D:\Karten\osm\Geofabrik\Duesseldorf.osm.pbf␣-b=6.75,51.45,6.85,51.5␣--drop-brokenrefs␣>␣bbox2.osm

oder halt mit -i statt <.

gruß,
ajoessen

ajoessen wrote:

Leider will abload.de die Bilder nicht rausrücken :-(

Geht mir genauso. :-(

ajoessen wrote:

Ist bei pbftoosm ausgeschlossen, dass Wege mit einem oder null Knoten in die Ausgabe gelangen?
Oder Multipolygone ohne outer?

Ich schließ besser mal gar nichts aus, weil ich nicht genau weiß, was du wissen willst. :-) Was meinst du mit "Nullknoten"? Also, eine Knotenreferenz in einem Weg auf einen Knoten, der außerhalb des Bereichs liegt und deshalb in der Datei nicht mehr enthalten ist? Das sollte ausgeschlossen sein durch die Option "--drop-brokenrefs". Gleiches gilt für die Referenzen auf Polygone, die nicht mehr in der Datei enthalten sind.
In solchen Fällen bringt der Composer aber auch eine konkrete Fehlermeldung.

HALT: Ich bin noch nicht ganz wach. :-)
Wie komm ich auf "Nullknoten"? Ich sollte wieder ins Bett. Also, nochmal:
Nein, das ist nicht ausgeschlossen. Wege mit 0 Knoten sind ausgeschlossen, da sie ja definitionsgemäß nicht im ausgeschnittenen Gebiet liegen KÖNNEN. Aber Wege mit einem Einzelknoten kann es theoretisch geben.

ajoessen wrote:

oder halt mit -i statt <.

Ja, bitte. :-) Sonst ist zu viel Schrott in der Ausgabedatei.

Hallo Zusammen
Ich hab die Bilder noch einmal hoch geladen.

Hoffentlich kommt Ihr jetzt dran.

Viele Grüße
tippeltappel

Marqqs wrote:

ajoessen wrote:

Leider will abload.de die Bilder nicht rausrücken :-(

Geht mir genauso. :-(

ajoessen wrote:

Ist bei pbftoosm ausgeschlossen, dass Wege mit einem oder null Knoten in die Ausgabe gelangen?
Oder Multipolygone ohne outer?

Nein, das ist nicht ausgeschlossen. Wege mit 0 Knoten sind ausgeschlossen, da sie ja definitionsgemäß nicht im ausgeschnittenen Gebiet liegen KÖNNEN. Aber Wege mit einem Einzelknoten kann es theoretisch geben.

Meinjanur, weil ich im Kurztest auf Relationen mit 0 Elementen gestoßen war. Die Nachverarbeiter erwarten nun mal korrekte OSM-Daten.

Gruß,
ajoessen

tippeltappel wrote:

Hallo Zusammen
Ich hab die Bilder noch einmal hoch geladen.

Hoffentlich kommt Ihr jetzt dran.

Viele Grüße
tippeltappel

Ja, nun sieht man was. Ne Lösung hab ich aber nicht parat.

Gruß,
ajoessen

tippeltappel wrote:

Ich hab die Bilder noch einmal hoch geladen.

Danke!
Das erste Bild deutet klar auf einen Fehler entweder IN pbftoosm oder evtl. in der Eingabedatei hin.
Verwendest du die Version 0.9 von pbftoosm? Bitte mal testen mit

pbftoosm␣-h

und dann die ersten Zeilen der Ausgabe anschauen (hochscrollen).
Aber eigentlich müsste ein solcher Fehler dann immer auftreten, also egal, welchen Ausschnitt du aus der Europa-Datei ausschneiden willst...

Der Fehler auf dem zweiten Bild ist eindeutig ein Folgefehler, weil ja die Ausgabedatei, die pbftoosm erzeugt hat, nicht vollständig ist.

@Marqqs
Die Europadatei habe ich nur ein einziges Mal für das Grenzgebiet Niederrhein ausprobiert.
Nach dieser Fehlermeldung habe ich dasselbe Gebiet noch einmal aus dem germany.osm.pbf ausgeschnitten.
Das funktionierte ohne Fehlermeldung.
Deshalb ist der Bereich in der Übersicht grün dargestellt.
Die Übersichtsgrafik bezieht sich ausschließlich auf Ausschnitte aus germany.osm.pbf.

Ja ich benutze pbftoosm V0.9 .

tippeltappel wrote:

@Marqqs
Die Europadatei habe ich nur ein einziges Mal für das Grenzgebiet Niederrhein ausprobiert.
Nach dieser Fehlermeldung habe ich dasselbe Gebiet noch einmal aus dem germany.osm.pbf ausgeschnitten.
Das funktionierte ohne Fehlermeldung.

Prüf bitte mal die Größe der Europa-Datei. wie viele Bytes hat sie genau?
Falls sie vollständig zu sein scheint, werde ich das selber testen und der Sache auf den Grund gehen. Das dauert allerdings ein bisschen, weil ich heute tagsüber nicht mehr dazu komme. Bis dahin benutz bitte die germany.osm.pbf - oder vielleicht kriegst du Osmosis doch noch zum Laufen und kannst damit die Europa-Datei mal testen.

Es gäb noch ein weiteres Konvertierungsprogramm für PBF->OSM, aber das ist bis jetzt nur als Quellcode verfügbar, also nur unter Linux einfach einsetzbar. Außer, du wagst dich an MinGW und übersetzt solche Programme selber:
http://forum.openstreetmap.org/viewtopi … 40#p162140

europe.osm.pbf - 5.981.195 KB

Das mit MinGW lasse ich lieber.

EDIT
Hab gerade ein neues europe-Download angeschmissen.

tippeltappel wrote:

europe.osm.pbf - 5.981.195 KB
EDIT
Hab gerade ein neues europe-Download angeschmissen.

Das könnte den 5,7 GB entsprechen, die hier genannt sind:
http://download.geofabrik.de/osm/

Würde vermuten, dass die Datei ok ist, aber sicher bin ich natürlich nicht.
Ich werd sie heute Abend mal runterladen und schauen, was passiert. Investier nicht zu viel Zeit. Falls hier ein Fehler in pbftoosm die Ursache ist, kommst du nicht weiter. Dann besser versuchen, die Datei mit Osmosis auszuschneiden.

@ Marqqs
Osmosis bekomme ich nicht ans Laufen, weil es die Ausgabedatei nicht schreiben kann.
Keine Ahnung, warum.

@ ajoessen
notepad++
finde ich auf meinem Rechner nicht.

Aber etwas anderes gibt es da:
Windows PowerShell
http://de.wikipedia.org/wiki/Windows_PowerShell

und
Windows PowerShell ISE
http://technet.microsoft.com/de-de/libr … 10%29.aspx

Mal sehen, ob ich da irgendwie einen Einstieg finde.

tippeltappel wrote:

@ Marqqs
Osmosis bekomme ich nicht ans Laufen, weil es die Ausgabedatei nicht schreiben kann.
Keine Ahnung, warum.

@ ajoessen
notepad++
finde ich auf meinem Rechner nicht.

Türlich nicht. Aber hier:
http://notepad-plus-plus.org/

Aber etwas anderes gibt es da:
Windows PowerShell
http://de.wikipedia.org/wiki/Windows_PowerShell

Da kann ich nix zu sagen.
Irgendwie sollte es aber doch möglich sein, die Schreibrechte für temp und Ausgabe hinzubekommen...

Gruß,m
ajoessen

tippeltappel wrote:

@ Marqqs
Osmosis bekomme ich nicht ans Laufen, weil es die Ausgabedatei nicht schreiben kann.
Keine Ahnung, warum.

@ ajoessen
notepad++
finde ich auf meinem Rechner nicht.

Aber etwas anderes gibt es da:
Windows PowerShell
http://de.wikipedia.org/wiki/Windows_PowerShell

und
Windows PowerShell ISE
http://technet.microsoft.com/de-de/libr … 10%29.aspx

Mal sehen, ob ich da irgendwie einen Einstieg finde.

Hallo Tippeltappel,

notepad++ muss man selbst installieren. Du kannst das schöne Programm hier finden: http://notepad-plus-plus.org/ Der Vorteil ist das es bei sehr vielen Sprachen bestimmte Befehle hervor hebt und so die Fehlersuche vereinfacht.
Für eine einfache Batchdatei reicht aber ein gewöhnlicher Texteditor. In die Batchdatei schreibst du nichts anderes rein als wie du es auf die Kommandozeile auch schreiben würdest. Eventuell musst du noch die Pfadangaben ergänzen, damit das Betriebssystem die Dateien auch findet.

Falls du keinen Editor suchen möchtest, kannst du im Explorer oder auf dem Desktop mit einem Rechtsklick einfach eine neue Textdatei anlegen. Diese kannst du dann in .bat umbenennen und mit Doppelklick ausführen. Für Inhalt sorgst du mit Rechtsklick und bearbeiten. Jetzt sollte sich der eingebaute Editor öffnen.

ajoessen wrote:

Da kann ich nix zu sagen.
Irgendwie sollte es aber doch möglich sein, die Schreibrechte für temp und Ausgabe hinzubekommen...

Gruß,m
ajoessen

Ich denke nicht das es daran liegt, dass keine Schreibrechte vorhanden sind. Das Problem liegt wahrscheinlich am Betriebssystem selber. Denn hier werden die Pfade ganz merkwürdig verwaltet. Man findet zwar einen Ordner Anwendungsdaten, aber darin ist nichts enthalten. Vielmehr braucht man den Ordner Appdata. Und so ähnlich wird es auch mit dem Tempverzeichnis sein. Auch andere Programme wie Openoffice öffnen E-Mailanhänge die ins Tempverzeichnis gewandert sind, schreibgeschützt. Erst nach nochmaligem speichern (auch im Tempverzeichnis) werden die Dateien bearbeitbar.

Eventuell hilft es also die Umgebungsvariablen anzupassen oder Osmosis dazu zu überreden die Tempdatei in einem anderen Verzeichnis abzulegen und nicht auf die globalen variablen zurückzugreifen.

Hab noch was gebastelt ...
Die in der Windows PowerShell ISE eingegebene Kommandozeile wurde verweigert.
Hatte keine Lust das zu dokumentieren und hab dann mit dem Texeditor einen Kommandoaufruf gespeichert.
Zuerst als *.bat
Im cmd-Fenster tauchte nach Aufruf der *bat eine 1 vor dem Namen der Ausgabedatei auf, was dann natürlich einen Fehler produzierte, weil es diesen Pfad nicht gibt.
Dieselbe Datei als *.exe abgespeichert führte dann zu einer Systemfehlermeldung (?).

Ich fürchte, mir bleibt nichts anderes übrig, als nächste Tage mal eine Festplatte mit XP aufzusetzen, damit geklärt werden kann, ob das, was ich da fabriziere total falsch oder einfach nur nicht Windows7-kompatibel ist.

Oder hat noch jemand eine Idee?

die 1 ist kein Problem. Warum springst du erst in das Verzeichnis? Für die bat doch gleich in dem Verzeichnis aus. 😉

Ich springe per batch in das Verzeichnis, damit ich das nicht vorher von Hand aufrufen muß.
Beim ersten Aufruf der cmd-Box steht die grundsätzlich in C:\User\Name.
Außerdem will ich mir eine eigene Festplatte für den ganzen Kartenkrempel einrichten. Dann brauch ich nur noch den Laufwerksbuchstaben im Verzeichnisaufruf zu ändern und alles paßt.

Wenn die 1 kein Problem ist, wo hakt es dann?

Gruß tt

aighes wrote:

die 1 ist kein Problem. Warum springst du erst in das Verzeichnis? Für die bat doch gleich in dem Verzeichnis aus. 😉

Ja, die 1 kommt auch bei mir unter XP. Ist irgendwie pbftoosm-spezifisch.
Mach doch mal zwei Zeilen draus:
cd c:\OSM_Rohdaten\pbf
pbftoosm.exe ...

Ausserdem hast du jetzt eine odenwald-pbf2osm batch-datei, und eine Anwendung gleichen Namens. das kann nicht gut gehen.

Naja, und ob das Programm überhaupt in einem "16-bit MS-DOS Subsystem" läuft...

Gruß,
ajoessen

tippeltappel wrote:

Ich springe per batch in das Verzeichnis, damit ich das nicht vorher von Hand aufrufen muß.
Beim ersten Aufruf der cmd-Box steht die grundsätzlich in C:\User\Name.

Startest du das über den Eintrag im Programm-menü?
Geh mal in der Menüzeile mit der rechten Maustaste auf Eigenschaften.
Bei mir steht da Ausführen in: %irgendwas.
Wenn du da E:\ einträgst, müsste cmd.exe auch dort starten.

gruß,
ajoessen

Also die Idee mit umbenennen in .exe ist leider ganz falsch. Hier erwartet Windows eine Ausführbare übersetzte Datei. Du kannst allenfalls versuchen diese Datei als .cmd zu speichern
Ein weiterer Versuch wäre wenn du unter ausführen zunächst cmd eingibst und dann erst aus der Dosbox die batchdatei aufrufst.

Die Odenwald...exe hab ich jetzt umbenannt, damit die nicht versehentlich angesprochen wird.
Die Odenwald...batch erzeugt nun eine Odenwald.osm allerdings mit 0KB und die Fehlermeldung ist unverändert.

Also Zeilenumbruch eingebaut.
Und - dasselbe?
Im ersten Moment dachte ich das.
Aber nein, die "Pause" kam ja gar nicht und die Fehlermeldung davor auch nicht ...

Ah, PC rechnet 1-2 Minuten (im Moment auf meinem PC die übliche Zeit für das germany.osm.pbf )
Und dann - schwupp Odenwald.osm fertig.
Ob es die Datei im Composer tut, guck ich jetzt nicht mehr.

Nun möchte ich Odenwald in einem anderen Ordner ablegen.
Also setze ich den entsprechenden Pfad vor den Dateinamen.
Ich hoffe, das funktioniert dann genauso gut.

Wenn ich Zeit zum Weiterbasteln habe, schreibe ich die Aufrufe für die anderen Kartenausschnitte mal alle hintereinander in eine batch.
Da bin ich gespannt, wie das dann funktioniert. 🙂

Danke für die Hilfe! 🙂

ajoessen wrote:

tippeltappel wrote:

Ich springe per batch in das Verzeichnis, damit ich das nicht vorher von Hand aufrufen muß.
Beim ersten Aufruf der cmd-Box steht die grundsätzlich in C:\User\Name.

Startest du das über den Eintrag im Programm-menü?
Geh mal in der Menüzeile mit der rechten Maustaste auf Eigenschaften.
Bei mir steht da Ausführen in: %irgendwas.
Wenn du da E:\ einträgst, müsste cmd.exe auch dort starten.

gruß,
ajoessen

Sorry, die Frage hatte ich übersehen.
Das Batch starte ich einfach per Doppelklick aus dem Explorer heraus.
Ich könnte auch eine Verknüpfung auf das Desktop oder im Startmenü oder sonst wohin legen.

Gruß
tippeltappel

ajoessen wrote:

Ja, die 1 kommt auch bei mir unter XP. Ist irgendwie pbftoosm-spezifisch.

Warum die 1 erscheint, weiß ich auch nicht, aber ich denk eher nicht, dass sie etwas mit dem Programm zu tun hat.
Beim Umlenken in eine Datei kann man die Standardausgabe umlenken oder aber die Fehlerausgabe.
1> steht für Standardausgabe (die normalen Daten, die ein Programm ausgibt).
2> steht für Fehlerausgabe (Fehlermeldungen, Warnungen, irgendwelche Infos).

Bei Linux ist das generell so, und ich glaub, bei Windows auch.

ja ist bei windows auch so und hat nichts mit pbftoosm zutun.

Hallo zusammen.
Dank Eurer Hilfe wird mein lang gehegter Wunsch endlich war: eine komplette Deutschlandkarte mit eigenem Kartenlayout. :-) Das hatte mein Rechner bislang nie gepackt. Nach der Reparatur ist er zwar flotter geworden, aber durch das Deutschlandfile kam ich mit Composer immer noch nicht durch.

Nun kann ich das Problem mit einem Trick umgehen:
Damit sich die Berechnung nicht an zu großen Input-Dateien aufhängt, hab ich mir eine batch-Datei geschrieben, die Deutschland entlang der Längen- und Breitengrade in 12 Rechtecke aufteilt. Jedes Rechteck ist 2.1 Grad hoch und 3.1 Grad breit. Die Nachkommastelle ist für die Überlappung. Sollte sich herausstellen, daß in einer dieser Regionen zu viele Daten stecken, kann man diese weiter aufteilen. Aber im Moment scheinen die Dateigrößen ok zu sein.
Da pbftoosm glatte, oder zumindest fast glatte Kanten schneidet, entstehen keine störenden Überdeckungen, wenn man das Rechteckeckpuzzle zusammensetzt. Optisch bildet die Karte dann eine Einheit. Doch über diese überlappenden Kanten kann nicht geroutet werden. Das ist mir aber egal. Innerhalb der Rechtecke könnte es vielleicht funktionieren.

Für jeden Kartenausschnitt muß jedesmal das entsprechende Planetfile komplett durchgearbeitet werden. Da pbftoosm dafür lediglich ca 2 Minuten benötigt, ist die Aufteilung der Deutschland-Daten in etwa 23 Minuten fertig. Mit OSMOSIS würde das Stunden dauern.
Nun sind die Datenbankhäppchen klein genug, daß Composer bzw. mein PC sich daran nicht mehr "verschluckt". Composer saust nun flink analysierend, berechnend und teilend durch die Päckchen durch und ich freu mich ^.^

Ich bin sehr gespannt, was mit dem Karteil passiert, das die Fehlerstelle enthält.

Hat da schon jemand gucken und eine Ursache erkennen können, wodurch die Störung südlich von Essen entsteht?

Als nächstes werde ich versuchen, diese Polygonboxen (oder so ähnlich) hinzubekommen, damit ich auch unregelmäßige Ausschnitte in einem Gruß hinbekommen kann. Irgendwo hab ich dafür eine Vorlage gesehen.

Gute Nacht alle miteinander!

tippeltappel wrote:

Dank Eurer Hilfe wird mein lang gehegter Wunsch endlich war: eine komplette Deutschlandkarte mit eigenem Kartenlayout. :-)

Gratuliere !!

tippeltappel wrote:

Ich bin sehr gespannt, was mit dem Karteil passiert, das die Fehlerstelle enthält.
Hat da schon jemand gucken und eine Ursache erkennen können, wodurch die Störung südlich von Essen entsteht?

Da bin ich auch sehr gespannt. Da Osmosis bei dir als alternative Testmöglichkeit nicht läuft, könntest du es mal mit osmconvert probieren. Der Aufruf ist minimal anders, weil das Programm nicht direkt auf die Daten zugreift, sondern temporäre Dateien benutzt:

osmconvert␣germany.osm.pbf␣-b=...(hier␣deine␣Koordinaten)...␣>essen.osm

Download von hier: http://wiki.openstreetmap.org/wiki/Osmconvert

tippeltappel wrote:

Als nächstes werde ich versuchen, diese Polygonboxen (oder so ähnlich) hinzubekommen, damit ich auch unregelmäßige Ausschnitte in einem Gruß hinbekommen kann. Irgendwo hab ich dafür eine Vorlage gesehen.

So genannte "Border-Polygone". Das sind Textdateien, die so aussehen wie hier beschrieben:
http://wiki.openstreetmap.org/wiki/Osmo … ile_Format
Schau dir einfach das Beispiel an - es ist eine Reihe von Koordinaten, die das Polygon für den Ausschnitt beschreiben.

Wenn du zwischendurch Zeit findest, hab ich auch eine Bitte an dich...

Kannst du testen, ob dein Projekt läuft, wenn du bei pbftoosm den Parameter --drop-history mitgibst? Falls es dann nicht mehr klappt, würde mich die Fehlermeldung interessieren. Ggf. muss ich dich dann noch um einen kleinen Versuch bitten. Mein Ziel ist es, die .osm-Dateien, die pbftoosm ausgibt, so weit wie möglich zu verkleinern, ohne den Inhalt zu "beschädigen". Das würde alles noch ein bisschen beschleunigen.

Schöne Nacht!

Moin
Es gibt eine gute und eine schlechte Nachricht.

Zuerst der Versuchsaufbau:
1. mit pbftoosm Deutschland in 12 Regionen aufgeteilt: 2.1 Breitengrade x 3.1 Längengrade
Diese Karte war dabei eine gute Hilfe:
http://www.mygeo.info/landkarten/deutsc … e_2009.png

2. In Composer exakt dieselben 12 Regionen festgelegt
D01 D02 D03
D04 D05 D06
D07 D08 D09
D10 D11 D12
Anmerkung: Das Fehlergebiet liegt in D04.

3. Einen Job "Deutschland" angelegt, der auf alle 12 Regionen zugreift.

Versuchsablauf:
Composer greift die Regionen in der Reihenfolge auf, in der sie in der Regionenliste stehen.
Er analysiert die Daten und legt nach weiteren Arbeitsschritten Dateien an, die am Ende für mkgmap die Berechnungsgrundlage für *.img, *.tbl und *.typ sind.
Zunächst wird jede Region separat abgearbeitet. Das geht recht zügig, da auch die Regionen mit den größten Datenmengen ein für die Leistungsfähigkeit meines PCs gut verarbeitbares Volumen haben.
Die Regionen beinhalten logischerweise sehr unterschiedliche Datenmengen. Das hat zur Folge, daß die Anzahl der für die verschiedenen Regionen erstellten Dateien variiert. Die jeweiligen Datenpakete sind an der Regionsbezeichnung eindeutig identifizierbar.
Diese Arbeit hatte Composer nach knapp 2 Stunden erledigt.

Nun wurde mkgmap aufgerufen .... und zack .... .... mkgmap failed ...

Die ganze Warterei nun vergebens?
Nein.

- Job aufgerufen, dann D4 aus der Regionauswahl entfernt. So wird das Fehlergebiet ausgespart.
- Ich hätte jetzt zusätzlich kleine Regionen auswählen können, die in D4 liegen und die Fehlerregion aussparen. Darauf verzichtete ich aber erst einmal.
- Die Datenberechnung wurde überall auf "bei Bedarf" gesetzt.
- Job neu gestartet.
- Composer erkennt die bereits erstellten Dateien als "current" und ruft nach einem schnell erledigten Kontrolldurchlauf mkgmap auf. Und ....

... es klappt!
Die Deutschlandkarte läßt sich in mapsource einbinden und benutzen.

Viele Grüße
tippeltappel

P.S.
Weitere Versuche frühestens heute Abend.

EDIT
Ich habe das germany.osm.pbf als Datengrundlage benutzt.

Richtig automatisiert - gefällt mir. :-)

Kurze Zwischenfrage:

--drop-history? :-)

Und... du hast mal geschrieben, dass es mit europe.osm.pbf Probleme gab. Welches Kommando genau oder welche Borderbox hast du zum Ausschneiden benutzt?

Vorhin hättet ihr mich reichlich verwirrt sehen können.

Aber inzwischen ....

Doch hübsch der Reihe nach.

Um die Fehlerzone weiter eingrenzen zu können, schrieb ich für pbf2osm ein batch, das die Fehlerzone in 4 Gebiete von 0.1x0.1 Grad gliederte.
Diese ließ ich aus germany.osm.pbf ausschneiden.
In Composer definierte ich 4 Jobs, die für diese 4 Gebiete (F1, F2, F3, F4) je eine Karte erstellten.
Das war blitzschnell erledig .... und jedes Mal wurde eine einwandfreie Karte erstellt.

Hä??????

Also einen Job erstellt, der die Regionen F1 F2 F3 F4 zu einer Karte verband.
Hmmmmmmm - funktionierte auch!

Nun das gesamte Gebiet F1-4 in einem Stück aus germany.osm.pbf ausgeschnitten.
Composer und mkgmap haben auch das anstandslos berechnet.

Hmmmmmmmm - So langsam wird's lustig.

Ok, neuer Job.
Rückgriff auf den Gestern verweigerten D4-Ausschnitt, in dem die Fehlerzone enthalten ist.
Daten verarbeiten = Bei Bedarf
Der Job ruft also jetzt D4 ganz allein auf.
Die Daten sind nicht (!) neu ausgeschnitten und sie werden daher auch nicht (!) von Composer neu berechnet (=current)
Berechnung der Segmentaufteilung ist aktiviert > wird daher durchgeführt.
Garmin-Karte berechnen: immer > wird durchgeführt

mkgmap akzeptiert alle Daten und liefert eine Karte für D4 einschließlich Fehlerzone ab.

Jetzt verstehe ich gar nichts mehr.

• grübel*
  

Könnte es sein, daß die Segmentaufteilung Gestern nicht aktiviert war?
Die Jobeinstellungen habe ich leider nicht per Screenshot dokumentiert. Kann es also nicht mehr nachsehen.
Und inzwischen hab ich da drin rumgeklickt. ....

Die Segmentaufteilung sorgt dafür, daß die Daten innerhalb einer Kachel ein bestimmtes Limit nicht überschreiten.
Ohne diese Berechnung kann es in Bereichen mit hohem Datenaufkommen zu einer Überschreitung des Limits kommen.
Wenn ich mich recht erinnere, stürzt mkgmap dann möglicherweise ab.
Damit das nicht passiert, hat Nop die automatische Berechnung der Segmentaufteilung eingebaut.

Nun gut.
Nächster Versuch.

Jobeinstellung für die komplette Deutschlandkarte:
Alle Regionen von D1 bis D12 aufrufen.
Daten verarbeiten = bei Bedarf (also nicht, da noch current=aktuell/nicht neu berechnet)
Berechnung der Segmentaufteilung = aktiviert
Maximale Objekte pro Kachel:1500
Garmin-Karte berechnen: immer

Die Berechnung der Segmentaufteilung dauert eine Weile ....

und dann .....

mkgmap wird aufgerufen.
Ich starre wie hypnotisiert auf den Bildschirm.
Keine Fehlermeldung ...
mkgmap rechnet ... und
ja!
Die ersten *.img tauchen im Explorerfenster auf.

Pro Minute werden ca 4 *.img ausgegeben.
Das dauert eine Weile. Das kann der PC alleine ....

Insgesamt wurden 102 *.img eine *.tbl und eine *.typ gebaut.
Das dauerte 28 Minuten.

Die Deutschland Karte ist jetzt komplett (ohne angrenzende Gebiete) und läuft in MapSource.

Anmerkung: Die Karte wurde ohne Höhenlinien erstellt.
Mit Höhenlinien würde das Datenvolumen und damit auch die Zahl der Kacheln (*.img) deutlich ansteigen.
Die Berechnung der Karte würde deutlich länger dauern.
Da ich offline ohnehin nicht ohne erheblichen Aufwand an die Höhendaten ran komme, verzichte ich fürs Erste auf die Höhenlinien.

Alle Versuche wurden ohne --drop-history und mit derselben Datenbasis germany.osm.pbf durchgeführt, damit Veränderungen in diesem Bereich als Ursache für veränderte Ergebnisse ausgeschlossen werden konnten.

Fazit -
1. kleiner Fehler - große Wirkung!
Was ein einziges Häkchen so ausmacht! 😉

2. Mit pbftoosm wird das Basteln einer Karte zum Vergnügen, weil pbftoosm das Datenarchiv blitzschnell zurecht schneidet und mit wenigen Rechnerresourcen auskommt. Der Effekt: Grenzgebiete rendern ist ab jetzt auch für Leute mit kleinen Rechnern möglich.
Für das Download des Europafiles muß man etwas Geduld mitbringen. Das Download der *.osm.pbf geht aber deutlich schneller als das Download der *.bz2-Archive. Für die europa.osm.pbf-Datei brauche ich ca 1:20. Das ist verkraftbar.
Entpacken und Ausschneiden des Europa-Files dauert mit pbftoosm nur wenige Minuten. Eine einmal ausgetüftelte batch-Datei läßt sich mit Mausklick aufrufen. Und schon wird die Datei blitzartig durchgeschleust.
Da ein Rechendurchgang so schnell ist, ist es auch kein Problem, in einem Rutsch gleich mehrere Regionen auszuschneiden. Auf diese Weise zerlegt man die Daten in handliche Input-Dateien, die der Rechnerleistung nach Belieben angepaßt werden können. Die Zeit für das Schneiden wird durch die Größe des Planetfiles bestimmt und nicht durch die Größe der ausgegebenen *.osm. Die Zeit für das Schreiben der *.osm hängt zwar von der darin enthaltenen Datenmenge ab, die Unterschiede sind aber bei den bislang erstellten Ausschnitten so gering, daß sie nicht groß ins Gewicht fallen. Für 12 Deutschland-Regionen benötigte ich insgesamt knapp 25 Minuten.
Die komplette Neuberechnung der Deutschlandkarte bis zur fertigen Karte besorgt dann Composer mit Unterstützung verschiedener Tools vollautomatisch. Die Zeit habe ich jetzt nicht ausgerechnet. Aber das ist überschaubar.

3. Großes Kompliment und Dankeschön an Marqqs für pbftoosm und an Nop für seinen Composer.

nächste Arbeitsschritte:
- neue batch-Datei anlegen, in der der Datenextrakt mit --drop-history zusätzlich reduziert wird.
- neue batch-Datei anlegen, in der die Grenzgebiete aus europa.osm.pbf ausgeschnitten werden > Deutschlandkarte mit Grenzgebieten.
- batch-Datei mit "krummen" Ausschnitten programmieren

Und wenn ich dann mal Langeweile hab und den Rechner grad nicht für andere Dinge brauch, dann bau ich mal eine Weltkarte *lach*
Achja, meine Ozeane sind noch leer. Aber ich wohne ja im Binnenland. Da muß ich das Meer nicht auf der Karte sehen. 😉
Aber vermutlich treibt mich die Neugierde dann doch eines Tages dazu, den virtuellen Wasserkran aufzudrehen. 😄

Ich glaub, jetzt kann ich einen Workshop anbieten: "Karte basteln leicht gemacht!" -

Gruß
tippeltappel

Och so ein Workshop wäre nicht schlecht. Vielleicht nicht nur für Garminkarten, sondern auch gleich für Webkarten*gg

@ viw
Mit Webkarten hab ich mich noch nicht befaßt.

[strong Arbeitsschritt
- neue batch-Datei anlegen, in der der Datenextrakt mit --drop-history zusätzlich reduziert wird.

• done

Ergebnis: die Datenmenge wurde deutlich reduziert

Zeitverbrauch der Arbeitsschritte zur Kartenberechnung:

0:10 Download germany.osm.pbf

0:17 pbftoosm schneidet 12 gleich große Rechtecke aus germany.osm.pbf aus;
Dateigröße sehr unterschiedlich, weil in den Gebieten unterschiedlich viel gemappt wird
und in Grenzbereichen ein Teil der Fläche leer ist;

Composer übernimmt
1:25 (Summe 1:52) Datenanalyse - Daten bearbeiten
0:25 (Summe 2:17) Segmentaufteilung
0:53 (Summe 3:10) Daten teilen - Ebenen sortieren
0:29 (Summe 3:39) Karte zusammenstellen mit mkgmap

Abschließende Betrachtung:
Composer ist so konzipiert, daß die Datenbeschaffung über einen Assistenten gesteuert wird. Dieser greift auf hinterlegte URLs von Geofabrik zu. Die Daten werden von Osmosis geschnitten. Der Zuschnitt wird im Composer durch das Anlegen von Regionen festgelegt.
Der Assistent zeigt sehr komfortabel an, welche Planetfiles für den gewünschten Kartenausschnitt infrage kommen.
Außerdem gibt er in Minuten an, mit welcher Verarbeitungsdauer zu rechnen ist.
Hinter dem Europafile steht eine schwindelerregende Zahl.
Das Ausschneiden von innereuropäischen Grenzgebieten würde also "ewig" dauern.

Da ich Composer offline einsetze, kann ich Composer zum Herunterladen und Schneiden von Planetfiles nicht nutzen.
Ich lade Planetfiles auf einen anderen Rechner herunter und übertrage sie dann manuell auf den Offline-Rechner.
Composer erkennt Planetfiles im bz2-Format sowie entpackte *.osm als lokale Dateien und verarbeitet diese ungeschnitten.
Je größer die Dateien sind, um so schleppender wird die Verarbeitung. Ab einer nicht näher erforschten Dateigröße bleibt Composer mit einem Java-Error (out of memory) stehen. Ein Deutschlandfile läßt sich mit meinem PC (32bit, quad Core) auf diese Weise nicht verarbeiten.

Die Lösung des Problems: pbftoosm
Programm und Befehle werden über eine Kommandozeile aufgerufen, die man in das DOS-Eingabefenster eintippt (start+r / enter > Eingabeaufforderung)
pbftoosm schneidet den gewünschten Bereich sehr viel schneller aus, als man es von osmosis gewöhnt ist.
Durch das Attribut --drop-history wird die Datenmenge drastisch gekürzt.
Das erleichtert die Weiterverarbeitung.

Durch das Schreiben einer batch-Datei kann man die Ausschneide-Aktion automatisieren.

Wenn die batch-Datei geschrieben und Composer den persönlichen Wünschen gemäß eingerichtet ist, reduziert sich die Arbeit beim Erstellen einer Karte auf wenige Handgriffe:
1. Download starten: Planetfile herunter laden (oder aktualisieren)
2. Batchdatei starten: Planetfile mit pbftoosm schneiden
3. Composer starten: Karte berechnen und installieren

Eine komplette Deutschlandkare läßt sich mit einem Trick auch auf kleinen Rechnern erstellen. Alles nur eine Frage der Zeit.
Dank pbftoosm ist der Zeitverbrauch für das Ausschneiden einer Grenzregion aus dem Europafile sehr schnell geworden.

Alles in allem dauert das Erstellen einer kompletten Deutschlandkarte auf meinem Rechner in der aktuellen Konstellation gerade mal rund 3:40h. Was will man mehr?
Bei Verwendung des Europafiles dauert das Download erheblich länger (1:20h). Wie das Erstellen der Ausschnitte funktioniert, werde ich probieren, wenn ich dafür das passende batch geschrieben habe.

Gute Nacht allerseits.
tippeltappel

tippeltappel wrote:

Mit Höhenlinien würde das Datenvolumen und damit auch die Zahl der Kacheln (*.img) deutlich ansteigen.
Die Berechnung der Karte würde deutlich länger dauern.
Da ich offline ohnehin nicht ohne erheblichen Aufwand an die Höhendaten ran komme, verzichte ich fürs Erste auf die Höhenlinien.

Also eigentlich ist das mit den Höhenlinien kein sooo großer Aufwand. Dafür gibt es SRTM2osm und Groundtruth. Die Laden sich die benötigten NASA-Daten einmalig runter, und stecken die in ein Cache-Unterverzeichnis. Im Dateinamen kannst du ablesen, welche 1°*1°-Kachel von 2,8MB Größe es sind. Wenn das Programm dann gestartet ist, nimmt es standardmäßig die Daten aus dem Unterordner; also komplett offline möglich.

Du musst nur einmalig am online-Rechner den Download anstoßen.

Ansonsten: Schön, dass es bei dir endlich läuft. Mein Garmin mag keine Karten, deshalb hab ich mich bisher nur um webfähige Rasterkarten gekümmert.

Gruß,
ajoessen

Moin

@ajoessen
Das Thema Höhenlinien / SRTM2osm müßte man in einem anderen Thread diskutieren.
Daher nur ein kurzer Hinweis.
SRTM2osm ist in Composer so integriert, daß die Höhenlinien für das in der Region definierte Gebiet automatisch herunter geladen werden.
Damit das passiert, setzt man bei der Konfiguration des Jobs ein Häkchen. Das ist alles.
Da braucht man dann über die Funktionsweise von SRMT2osm nicht eine Sekunde nachdenken.
Genau das ist ja Sinn und Zweck von Composer und macht es dem Anwender so einfach.

Der in meinen Augen erhebliche Mehraufwand besteht darin, daß ich mich erst einmal in die Funktionsweise von SRMT2osm http://wiki.openstreetmap.org/wiki/Srtm2Osm hineinfuseln muß.
Das heißt: Programm einrichten, batches schreiben, gucken, wie das Download funktioniert, gucken, wie ich den Zugriff von Composer auf das Download einrichten kann. Vor allem für letzteres hätte ich im Moment noch gar keine Idee. ...
Jedesmal wenn ich eine neue Kartenregion im Composer definiere, muß ich dann auch für Srtm2Osm ein neues batch schreiben, ein neues Download anstoßen .....
Das alles finde ich ziemlich viel Aufwand und ist mir die Sache nicht wert.
Aber das ist hier ja eigentlich nicht das Thema.

@ marqqs
Gleich habe ich kurz Zeit für den nächsten Arbeitsschritt.
- neue batch-Datei anlegen, in der die Grenzgebiete aus europa.osm.pbf ausgeschnitten werden > Deutschlandkarte mit Grenzgebieten.

Ursprünglich wollte ich das pbftoosm-Deutschland-batch folgendermaßen auf die Verwendung des Europafiles umschreiben:
- im Datenquellen-Assistent von Composer sehe ich nach, welche für welche der 12 Zonen zwingend das Europafile benötigt wird
- für diese Zonen tausche ich die Datenquelle germany.osm.pbf gegen europe.osm.pbf aus
Dabei wollte ich bewußt inkauf nehmen, daß die beiden Datenquellen nicht denselben Zeitstempel haben. Da die Zonen D1, D2 .... von Composer imgrunde als eigenständige Karten behandelt werden, die lediglich wie Overheadfolien übereinander gelegt und nicht tatsächlich in Verbindung gebracht werden, sollte das kein Problem sein.
Die Zeitersparnis, die ich mir davon versprach, ist aber so gering, daß sie durch das zusätzliche Download von germany.osm.pbf wieder aufgehoben wird. Denn:
Das Europafile wird für 10 von 12 Deutschlandzonen zu je 2.1° x 3.1° benötigt.
Lediglich 2 Zonen berühren keine Grenzen.
Da pbftoosm so schnell ist, ist die Zeitersparnis für diese 2 Zonen unbedeutend.
Also kann ich mir bei der Verwendung von pbftoosm das germany.osm.pbf sparen und alle Ausschnitte aus dem Europafile holen.

Gruß
tippeltappel

Fehlermeldung beim Auslesen des Europafiles

todo: das Anzeigen der Systemzeit in die batch einfügen, damit man den Zeitablauf erkennen kann

Gruß
tt

Die Grafik zeigt einen Vergleich des Arbeitstempos von pbftoosm mit und ohne --drop-history:

--drop-history beschleunigt das Erstellen der Ausgabedatei.
Das sind für das einzelne Segment zwar nur ein paar Sekunden. Aber wenn viele Segmente geschnitten werden sollen, summiert sich das.

echo %time% löst dein Problem mit der Zeit.

aighes wrote:

echo %time% löst dein Problem mit der Zeit.

Welches Problem?

tippeltappel wrote:

Fehlermeldung beim Auslesen des Europafiles

Sorry, konnte ne Weile nicht ins Forum schauen. Danke für den Test mit dem Europafile! Ich werd versuchen, den Fehler zu erjagen. :-)

Wäre super, wenn Du den findest! 🙂
Dann könnte ich auch die Eifel ausschneiden.
Das ist ja Grenzgebiet.

Viele andere würden sich ebenfalls freuen!
Die ganzen Überlegungen mit Deutschland+50km oder ähnliches könnte man dann getrost abhaken, weil man sich dann die Daten mit pbftoosm in kurzer Zeit auch mit einem kleinen Rechner selbst passend schneiden kann. Frederik wird sich dann sicherlich wundern, wie oft das Europafile plötzlich herunter geladen wird. 😉

Zwischendurch hab ich die ein oder andere Batch-Variante erstellt und den Composer mit unterschiedlich großen *.osm gefüttert, um herauszufinden, bei welcher Datenmenge das out-of-memory kommt.
Jetzt, wo ich weiß, wie das geht, ist es ganz einfach.

Wie Du an der letzten Grafik erkennen kannst, läßt sich an den Start- und Endzeiten sehr schön ablesen, wie lange pbftoosm für das Ausschneiden der Dateien mit und ohne --drop-history benötigt.
Vom Ausschneiden der 12 D-Segmente hab ich auch ein Screenshot.
Wenn Du davon etwas sehen möchtest, lade ich es Dir hoch.

Europa sollte man sich dann vom gwdg-Mirror holen...;)...denn der Geofabrik-Traffic ist auch limitiert. Aber da wird man dann meist ohnehin umgeleitet.

tippeltappel wrote:

Wäre super, wenn Du den findest! 🙂
Dann könnte ich auch die Eifel ausschneiden.
Das ist ja Grenzgebiet.

Ich find den Fehler nicht. :-( Dummerweise tritt er hier nicht auf. Ich hab europe.osm.pbf grad runtergeladen (6165941463 Bytes groß) und mit so verarbeitet:

$␣time␣./pbftoosm␣-i=europe.osm.pbf␣-b=6,53,9.1,55.5␣--drop-broken-refs␣--drop-history␣>e.osm
real␣␣␣␣11m15.541s
user␣␣␣␣9m17.087s
sys␣␣␣␣0m20.005s

Herausgekommen ist eine einwandfreie .osm-Datei mit 700069877 Bytes Größe:

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version="0.6"␣generator="pbftoosm">
<bounds␣minlat="53."␣minlon="6."␣maxlat="55.5"␣maxlon="9.0999999"/>
<node␣id="117950"␣lat="55.498373"␣lon="8.4442403">
<tag␣k="highway"␣v="mini_roundabout"␣/>
</node>
<node␣id="117954"␣lat="55.4977099"␣lon="8.4435082"/>
(...)
<relation␣id="1602066">
<member␣type="way"␣ref="114994596"␣role="inner"/>
<member␣type="way"␣ref="114777344"␣role="outer"/>
<tag␣k="type"␣v="multipolygon"␣/>
</relation>
</osm>

Natürlich freu ich mich, dass der Fehler nicht auftritt, aber im Grunde ist es doof, denn dann find ich ihn nicht.

Hmmmm - Dann lad ich mir auch noch schnell ein neues Europa herunter, damit wir mit derselben Datei arbeiten.

EDIT
Frage zu den Zeitangaben in der 2. Box:
Habe in meinem alten DOS-Schinken gelesen, daß man Systemzeiten nicht nur anzeigen sondern auch berechnen lassen kann, wieviel Zeit von einem Zeitpunkt x an vergangen ist.
Ist das so etwas?

tippeltappel wrote:

Frage zu den Zeitangaben in der 2. Box:
Habe in meinem alten DOS-Schinken gelesen, daß man Systemzeiten nicht nur anzeigen sondern auch berechnen lassen kann, wieviel Zeit von einem Zeitpunkt x an vergangen ist.
Ist das so etwas?

Das geht sicher auch in der Windows-Kommandozeile irgendwie... aighes hat da sicher einen Tipp, ich arbeite nicht oft mit Windows.
Unter Linux verwende ich dazu den Befehl "time". Wenn man "time" vor irgendwelche anderen Befehle schreibt, dann wird die Bearbeitungszeit so ausgedrückt, wie du das oben sehen kannst.
Unter Windows gibts auch einen Befehl "time", aber ich glaub, der zeigt nur die aktuelle Uhrzeit an.

@tippeltappel:
Wenn du noch Lust aufs Optimieren hast, kannst du mit o5mfilter experimentieren.
Statistik erstellen:

o5mfilter␣irgendwas.osm␣--out-count␣>tagliste.txt

Wenn da ganz oben viele Tags auftauchen, die keiner braucht, kannst du sie rausfiltern. Zum Beispiel:

o5mfilter␣irgendwas.osm␣--drop-tags="created_by=␣source=␣note="␣>gefiltert.osm

Oder du erstellst eine Positivliste mit allen Tags, die du brauchst. Dazu hilft eine alphabetisch sortierte Tag-Liste:

o5mfilter␣irgendwas.osm␣--out-keys␣>tagliste.txt

Marqqs wrote:

tippeltappel wrote:

Frage zu den Zeitangaben in der 2. Box:
Habe in meinem alten DOS-Schinken gelesen, daß man Systemzeiten nicht nur anzeigen sondern auch berechnen lassen kann, wieviel Zeit von einem Zeitpunkt x an vergangen ist.
Ist das so etwas?

Das geht sicher auch in der Windows-Kommandozeile irgendwie... aighes hat da sicher einen Tipp, ich arbeite nicht oft mit Windows.
Unter Linux verwende ich dazu den Befehl "time". Wenn man "time" vor irgendwelche anderen Befehle schreibt, dann wird die Bearbeitungszeit so ausgedrückt, wie du das oben sehen kannst.
Unter Windows gibts auch einen Befehl "time", aber ich glaub, der zeigt nur die aktuelle Uhrzeit an.

Ja, wenn ich das hier > http://de.wikibooks.org/wiki/Batch-Prog … t_anzeigen
richtig verstehe, ist das so.

Marqqs wrote:

@tippeltappel:
Wenn du noch Lust aufs Optimieren hast, kannst du mit o5mfilter experimentieren.
Statistik erstellen:

o5mfilter␣irgendwas.osm␣--out-count␣>tagliste.txt

Wenn da ganz oben viele Tags auftauchen, die keiner braucht, kannst du sie rausfiltern. Zum Beispiel:

o5mfilter␣irgendwas.osm␣--drop-tags="created_by=␣source=␣note="␣>gefiltert.osm

Oder du erstellst eine Positivliste mit allen Tags, die du brauchst. Dazu hilft eine alphabetisch sortierte Tag-Liste:

o5mfilter␣irgendwas.osm␣--out-keys␣>tagliste.txt

Danke. 🙂
Im Moment bin ich in den freien Minuten damit beschäftigt, mir ein Batch-Menü mit Unterroutinen zu schreiben.
Das lege ich dann auf das Desktop oder in die Start-Leiste. Wenn ich pbftoosm starten möchte, rufe ich das dann auf und kann auswählen, wieviele und welche Kartendaten ich aktualisieren möchte.
Das mache ich erst mal fertig, ehe ich etwas Neues anfange.

Schlechte Nachricht -
Wieder nix!

Die Fehlermeldung ist exakt dieselbe.
Habe jeden Buchstaben verglichen.

Und nun?

Gruß
tippeltappel

Hi,

kannst Du mal einen
md5sum
uener Deine Datei laufen lassen?

Mt dem berechneten Hash koennt Ihr dann wirklich vergleichen, ob Eure Dateien gleich sind.

Ciao,
Frank

kellerma wrote:

... md5sum ...

Ciao,
Frank

Kenne ich leider nicht.
Und das, was die Suchmaschine an Links ausspuckt ist vielfältig und zumindest auf den ersten Blick ziemlich verwirrend.

Gruß
tippeltappel

Mmh,
Ok, nimm http://support.microsoft.com/kb/841290

Ich habe heute auch einmal das Europafile von heute getestet. MD5: 0D8759263CB63C22B270F6CB371B22E6 europe.osm.pbf
Der Fehler ist im Prinzip ähnlich wie bei Tippeltappel. Ich benutze aber WinXP SP3
pbftoosm Warning: main-element type unknown: 0x88 0x3C.
pbftoosm Warning: main-element type unknown: 0x33 0x75.
pbftoosm: Format error: 0x33.
pbftoosm: Number of bytes read: 1838503371
pbftoosm: Next bytes to parse:
75 0E 34 E9 78 10 07 0D

Die Befehlszeile war die gleiche wie bei Tippeltappel
k:\>pbftoosm.exe -i=europe.osm.pbf -b=6,53,9.1,55.5 --drop-brokenrefs --drop-history 1>k:\osm\test.osm

Gibt es irgendwelche Ideen? werden irgendwelche Dateien gebraucht oder kann man noch etwas einstellen, damit die Fehlersuche einfacher wird?

viw wrote:

Gibt es irgendwelche Ideen? werden irgendwelche Dateien gebraucht oder kann man noch etwas einstellen, damit die Fehlersuche einfacher wird?

Gute Nachricht:
Ich konnte den Fehler reproduzieren. Er tritt auch unter Linux auf, wenn man die Windows-Version von pbftoosm verwendet (mit der Windows-Kompatiblitätsschicht "Wine"). Es sieht so aus, als würde die Umwandlung dort abbrechen, wo die erste Relation gelesen wird. Alle Nodes und Ways sind dann nämlich schon ordentlich in der Ausgabedatei.

Schlechte Nachricht:
Der Fehler ist noch drin. Ich hab Testausgaben ins Programm eingebaut, vielleicht finde ich ihn. Ich vermute, dass es unter Windows Probleme mit der Funktion "lseek()" gibt, wenn die Datei eine bestimmte Größe überschreitet.

Gute Nachricht:
Beim Programm osmconvert tritt der Fehler nicht auf. Das erscheint mir auch logisch, weil osmconvert nicht mit Datei-Direktzugriffen arbeitet (keine Option -i= ), sondern stattdessen zwei temporäre Dateien schreibt. Bis der Fehler in pbftoosm ausgebessert ist (falls es nicht ein unlösbarer Windows-Fehler ist), kann ich nur empfehlen, in diesem Fall statt pbftoosm die Alternative osmconvert zu verwenden:

osmconvert␣europe.osm.pbf␣-b=6,53,9.1,55.5␣--drop-broken-refs␣--drop-history␣>e.osm

Marqqs wrote:

Der Fehler ist noch drin. Ich hab Testausgaben ins Programm eingebaut, vielleicht finde ich ihn. Ich vermute, dass es unter Windows Probleme mit der Funktion "lseek()" gibt, wenn die Datei eine bestimmte Größe überschreitet.

Vermutung hat sich bestätigt, die Länge des Variablentyps off_t ist unter Windows 4 Bytes, unter Linux 8, obwohl in beiden Fällen mit "_FILE_OFFSET_BITS 64" übersetzt worden ist. Dürfte eigentlich nicht sein, aber ich weiß, wie ich es umschiffen kann. Teste grade.

Erledigt. Neue Version 0.10 umschifft das Windows-Problem mit den Dateien > 2 GB.

Danke euch für die Hinweise und Versuche!

Ich hätt da mal ne Frage 😉

Weil ich gerade sehe, dass Du noch eine Änderung vorgenommen hast:
$ diff 0.10/xaa 0.9/xaa
2c2
< <osm version="0.6" generator="pbftoosm 0.10">

---

<osm version="0.6" generator="pbftoosm">

34880c34880
< <tag k="note" v="verkehrsinsel (~ 10x2,5m) zur verkehrsberuhigung" />

---

<tag k="note" v="verkehrsinsel (&#126; 10x2,5m) zur verkehrsberuhigung" />

83534c83534
< <tag k="website" v="http://www2.kubiss.de/~phpk206/" />

---

<tag k="website" v="http://www2.kubiss.de/&#126;phpk206/" />

Soll dann dies auch so sein?

$ grep "&#" mittelfranken_0.10.osm| head
<tag k="note" v="accurate to &#60;2m" />
<tag k="website" v="https://www.kreissparkasse-hoechstadt.de/module/ihre_sparkasse/filialfinder/index.php?n=%2Fmodule%2Fkontakt%2Fkontakt_filialfinder%2F&#38;IFLBSERVERID=IF@@053@@IF" />
<tag k="name" v="McDonald&#39;s" />
<tag k="name" v="nah &#38; gut" />
<tag k="name" v="Lette&#39;m Sleep" />
<tag k="name" v="Kistl&#39;a" />
<tag k="name" v="Gasthaus &#34;Zum Eckenhaider Schloß&#34;" />
<tag k="name" v="Sky&#39;s Pizza" />
<tag k="name" v="O&#39;Sheas" />
<tag k="name" v="50&#39;s Diner" />
$

Danke.

Ciao,
Frank

Die Reperatur war erfolgreich!
ABER die Ausgabedatei von pbftoosm ist bei mir trotz gleicher Koordinaten etwas größer und die Verarbeitung dauert ca. 1 Minute länger als mit osmconvert. Wo liegen die möglichen Unterschiede?

kellerma wrote:

Ich hätt da mal ne Frage 😉

Guuut aufgepasst. :-)

Die Tilde muss normalerweise nicht per Escape-Code codiert werden. Das hab ich wieder rausgenommen, spart ein paar Bytes. War aber vorher auch nicht falsch, denn sie DARF codiert werden.
Anführungszeichen und Hochkomma erscheinen üblicherweise auch codiert, sonst ist der Syntax nicht mehr eindeutig. Das machen auch pbf2osm und Osmosis so.

Hier steht ein bisschen drüber: http://en.wikipedia.org/wiki/Xml#Escaping

@viv: Längenunterschiede ergeben sich durch diese Esc-Codierung und möglicherweise durch Blanks oder CR-Zeichen. Du kannst mal ein "diff -w" drüberlaufen lassen. Weiß aber grad nicht, ob das bei Windows genauso geht.

Klasse! Jetzt funzt es!

Dank pbftoosm V.10 ist es jetzt problemlos möglich, mit einem 4-Kern 32-bit innerhalb weniger Minuten ein Grenzgebiet aus dem Europafile zu schneiden. Die Daten wurden von Composer ohne Mucken durch die Tools geschleust.

Einen Hänger hab ich trotzdem "hinbekommen". Ein kompletter Querstreifen von Holland bis Polen 2.1° x 9.3°, der das sehr dicht gemappte Rhein/Ruhrgebiet enthält, ergab eine so große Datei, daß Composer mit Java Error Out of Memory stehen blieb.

Die 12 Rechtecke mit 2.1°x3.1° ergeben dagegen handliche Dateigrößen. Naja, im Moment. Die Datenmenge wächst ja Tag für Tag. 😉

Vielleicht kann man da ja mit zusätzlichen --drop-xyz etwas machen?

Im Composer ist z.B. eingestellt, daß die ganzen Hausnummern rausgeworfen werden.
Wozu dann vorher in die xyz.osm einlesen?
Das bläht die Datei doch nur unnötig auf.

Wäre es machbar, hinter --drop-brokenrefs --drop-history noch soetwas wie --drop-adress:housenumber einzubauen?

Hat aber keine Eile.
Die Kartenbastelei muß jetzt ein paar Tage ruhen.

tippeltappel

tippeltappel wrote:

http://www.cosgan.de/smiliegenerator/ablage/770/178.png Klasse! Jetzt funzt es!

Dank pbftoosm V.10 ist es jetzt problemlos möglich, mit einem 4-Kern 32-bit innerhalb weniger Minuten ein Grenzgebiet aus dem Europafile zu schneiden. Die Daten wurden von Composer ohne Mucken durch die Tools geschleust.

Einen Hänger hab ich trotzdem "hinbekommen". Ein kompletter Querstreifen von Holland bis Polen 2.1° x 9.3°, der das sehr dicht gemappte Rhein/Ruhrgebiet enthält, ergab eine so große Datei, daß Composer mit Java Error Out of Memory stehen blieb.

Die 12 Rechtecke mit 2.1°x3.1° ergeben dagegen handliche Dateigrößen. Naja, im Moment. Die Datenmenge wächst ja Tag für Tag. 😉

Vielleicht kann man da ja mit zusätzlichen --drop-xyz etwas machen?

Im Composer ist z.B. eingestellt, daß die ganzen Hausnummern rausgeworfen werden.
Wozu dann vorher in die xyz.osm einlesen?
Das bläht die Datei doch nur unnötig auf.

Wäre es machbar, hinter --drop-brokenrefs --drop-history noch soetwas wie --drop-adress:housenumber einzubauen?

Hat aber keine Eile.
Die Kartenbastelei muß jetzt ein paar Tage ruhen.

http://www.cosgan.de/images/smilie/muede/a025.gif tippeltappel

Natürlich ist das möglich. Aber dafür hattest du bisher ja noch keine Zeit: http://forum.openstreetmap.org/viewtopic.php?id=12302
Dieses Programm macht genau das was du willst. Die unerwünschten Keys fliegen raus. oder nur die gewünschten Keys kommen weiter.
Dafür ist es aber wie am Ende zu lesen war besser das PBF mit OSM convert in das o5m Format zu überführen. Das lässt sich schneller und besser filtern. Mit dem Tool o5mfilter erhält man dann als Ausgabe auch wieder ein osm file.

Freut mich, dass es nun klappt! :-)

tippeltappel wrote:

Wäre es machbar, hinter --drop-brokenrefs --drop-history noch soetwas wie --drop-adress:housenumber einzubauen?

Das wäre praktisch eine Filterfunktion für pbftoosm. Geht aber jetzt auch schon mit o5mfilter. Lässt sich sicher in dein Script mit einbauen, wenn du in diese Richtung experimentieren willst...

tippeltappel wrote:

Vielleicht kann man da ja mit zusätzlichen --drop-xyz etwas machen?

Im Composer ist z.B. eingestellt, daß die ganzen Hausnummern rausgeworfen werden.

Aha, jetzt brauchst Du es also doch, Markus' o5mfilter 😉

osmconvert.exe europe.osm.pbf -b=6,53,9.1,55.5 --drop-broken-refs --drop-history --out-o5m > tippel.o5m
o5mfilter.exe --drop-tags="addr:housenumber=" tippel.o5m > tappel.osm

Ciao,
Frank

@ Marqqs
Verstehe. Mit pbftoosm wäre es halt einfacher gewesen.
Aber ich hab mir das schon so gedacht.
Mit einem gut durchstrukturiertem Skript läßt sich da bestimmt etwas Nettes zaubern.
Wenn ich meinen anderen Kram erledigt habe, setze ich mich da bestimmt vor lauter Neugier noch einmal dran.

@ kellerma
Brauchen?
Weiß ich noch nicht.
Kommt drauf an.

Daß ich spezielle Projekte mit dem o5mfilter probieren möchte, hab ich ja schon geschrieben.

Nachdem ich nun verschiedene batches erstellt und diese auch noch mit Hilfe einer anderen batch mit Menü Nutzerabfrage Anspringpunkten Loops und weiß der Geier was alles organisert habe, obwohl ich vor wenigen Tagen nicht mal mehr wußte, wie man diese cmd-Box findet, könnte ich ja eigentlich weiter machen mit programmieren. Aber leider fehlt mir dann die Zeit woanders.

Das Ziel, Karten für Grenzgebiete auf Kopfdruck erstellen, ist erreicht.
Also lasse ich es erst einmal dabei bewenden. Denn wenn das zusätzliche Ausfiltern mit pbf2osm nicht geht, muß man eine Chain bauen, in der alle Filterschritte hintereinander abgearbeitet werden, bis die *.osm auf das absolute Minimum beschränkt ist. Aufwand und Nutzen stehen da für mich z.Zt. in einem ungünstigen Verhältnis. Klar, je mehr man die *.osm minimieren kann, um so großer wird das Gebiet, dessen Daten man ungeschnitten mit einem kleinen Rechner rendern kann. Das ist schon interessant, aber im Moment nicht notwendig.

Den umgekehrten Weg, nur ein paar projektspezivische Objekte aufzurufen, um diese dann in eine "verdaubare" Deutschland oder sogar Europa-Datei abzulegen, finde ich viel spannender und lohnender.
Mal sehen, wann ich dazu komme.

In den nächsten Tagen sicherlich nicht.

Viele Grüße
tipppeltappel