PBFtoOSM - Windows

Marqqs · 2011-05-18 22:03:05

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.

Sockeye · 2011-05-19 13:28:33

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

Marqqs · 2011-05-19 17:21:53

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.

PA94 · 2011-05-19 19:10:38

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

Marqqs · 2011-05-23 11:48:39

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

ajoessen · 2011-05-23 14:06:55

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

Marqqs · 2011-05-23 14:23:08

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.

tippeltappel · 2011-05-24 02:39:18

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

Marqqs · 2011-05-24 07:02:55

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.

Last edited by Marqqs (2011-05-24 07:05:52)

Marqqs · 2011-05-24 07:11:55

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

kellerma · 2011-05-24 08:16:35

@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

tippeltappel · 2011-05-24 11:02:41

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

????????

Last edited by tippeltappel (2011-05-24 12:23:53)

Marqqs · 2011-05-24 15:07:45

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

tippeltappel · 2011-05-24 18:00:25

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

tippeltappel · 2011-05-25 00:50:20

@ Marqqs

Was bedeutet das?
Fehlermeldung von pbftoosm:

Reaktion von Composer:

Gruß
tippeltappel

tippeltappel · 2011-05-25 04:42:28

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

Last edited by tippeltappel (2011-05-25 04:45:14)

ajoessen · 2011-05-25 06:55:46

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

Marqqs · 2011-05-25 08:15:00

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.

tippeltappel · 2011-05-25 08:24:11

Hallo Zusammen
Ich hab die Bilder noch einmal hoch geladen.

Hoffentlich kommt Ihr jetzt dran.

Viele Grüße
tippeltappel

ajoessen · 2011-05-25 08:28:10

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

ajoessen · 2011-05-25 08:29:35

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

Marqqs · 2011-05-25 08:33:12

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.

tippeltappel · 2011-05-25 08:44:36

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

Marqqs · 2011-05-25 08:56:09

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

tippeltappel · 2011-05-25 09:12:43

europe.osm.pbf - 5.981.195 KB

Das mit MinGW lasse ich lieber.

EDIT
Hab gerade ein neues europe-Download angeschmissen.

Last edited by tippeltappel (2011-05-25 09:14:29)

Announcement

#26 2011-05-18 22:03:05

Re: PBFtoOSM - Windows

#27 2011-05-19 13:28:33

Re: PBFtoOSM - Windows

#28 2011-05-19 17:21:53

Re: PBFtoOSM - Windows

#29 2011-05-19 19:10:38

Re: PBFtoOSM - Windows

#30 2011-05-23 11:48:39

Re: PBFtoOSM - Windows

#31 2011-05-23 14:06:55

Re: PBFtoOSM - Windows

#32 2011-05-23 14:23:08

Re: PBFtoOSM - Windows

#33 2011-05-24 02:39:18

Re: PBFtoOSM - Windows

#34 2011-05-24 07:02:55

Re: PBFtoOSM - Windows

#35 2011-05-24 07:11:55

Re: PBFtoOSM - Windows

#36 2011-05-24 08:16:35

Re: PBFtoOSM - Windows

#37 2011-05-24 11:02:41

Re: PBFtoOSM - Windows

#38 2011-05-24 15:07:45

Re: PBFtoOSM - Windows

#39 2011-05-24 18:00:25

Re: PBFtoOSM - Windows

#40 2011-05-25 00:50:20

Re: PBFtoOSM - Windows

#41 2011-05-25 04:42:28

Re: PBFtoOSM - Windows

#42 2011-05-25 06:55:46

Re: PBFtoOSM - Windows

#43 2011-05-25 08:15:00

Re: PBFtoOSM - Windows

#44 2011-05-25 08:24:11

Re: PBFtoOSM - Windows

#45 2011-05-25 08:28:10

Re: PBFtoOSM - Windows

#46 2011-05-25 08:29:35

Re: PBFtoOSM - Windows

#47 2011-05-25 08:33:12

Re: PBFtoOSM - Windows

#48 2011-05-25 08:44:36

Re: PBFtoOSM - Windows

#49 2011-05-25 08:56:09

Re: PBFtoOSM - Windows

#50 2011-05-25 09:12:43

Re: PBFtoOSM - Windows

Board footer