osmconvert schreibt PBF

aighes · 2011-10-17T14:58:57.000Z

So…osmupdate ist gerade durchgelaufen:

Fallstrick: PATH-Variable brauchte einen Eintrag für osmconvert wurde übersprungen

Das Verhalten von viw kann ich bestätigen. Ein Kern ist voll ausgelastet, HDD und RAM hätten noch Platz. Da die Reihenfolge der Objekte an sich ja egal ist, könnte man mehrere Threads machen, die nach einander ein Objekt einlesen und an einem Schreibe-Thread übergeben. Evtl. könnte man das packen der Blöcke auch in einen Thread auslagern.

Ein planet-update-race mach ich dann, mal später.

Noch eine Anmerkung zu osmupdate: Wäre es möglich den Update-Server einzustellen?

Noch eine Anmerkung zur Ausgabe der Timestamps: Ich fände es recht sinnvoll, die Zeit in der lokalen Zeit zu haben, weiß aber nicht ob sich das plattformübergreifend lösen lässt. Ansonsten evtl. der Hinweis, dass es UTC ist.

Ich hab mir MinGW von nuwen geholt, damit hat das -o3 leider nicht geklappt. Hat jemand eine Idee, woran das liegen könnte?

kellerma · 2011-10-17T15:19:10.000Z

aighes:

Noch eine Anmerkung zur Ausgabe der Timestamps: Ich fände es recht sinnvoll, die Zeit in der lokalen Zeit zu haben, weiß aber nicht ob sich das plattformübergreifend lösen lässt. Ansonsten evtl. der Hinweis, dass es UTC ist.

Steht doch dabei
osmupdate: timestamp of Nürnberg.osm: 2011-10-07T19:29:52Z

Z steht für Zulu was UTC ist.

aighes:

Ich hab mir MinGW von nuwen geholt, damit hat das -o3 leider nicht geklappt. Hat jemand eine Idee, woran das liegen könnte?

Klar. Klarer Fall von falschem OS
Mit Linux wäre Dir das nicht passiert, da könntest Du -O7 sogar nehmen

Ciao,
Frank

PS
“-O7” bringt ober nix

aighes · 2011-10-17T15:28:12.000Z

Tatsache…das Z hatte ich übersehen…

Gibts denn etwas alternatives für Windows?

aighes · 2011-10-17T15:37:16.000Z

Mittlerweile haben sich splitter und mkgmap durch die Daten gewuselt. Leider mit sehr mäßigem Erfolg. Das was aus dem Splitter kommt ist deutlich zu klein, er lief aber ohne Fehlermeldung durch. dementsprechend fehlen in der Karte dann auch sehr viele Objekte.

kellerma · 2011-10-17T15:51:07.000Z

Hallo Henning,

hast Du es für splitter & mkgmap mal mit der Option “–emulate-osmosis” probiert?
(Hab’ die proggies selbst nicht und kann sie deshalb auch nicht testen)

Das osm2pgsql hat jedenfalls anstandlos alles geschluckt.

Ciao,
Frank

EDIT:
Der “–emulate-osmosis” hat noch seine Tücken:
$ diff Nürnberg.osmosis.osm Nürnberg.osmconvert-emulate-osmosis.osm
3d2
<
1308487c1308486
<

<member type="node" ref="31165489" role="location_hint 	"/>

1353401a1353401

Marqqs · 2011-10-17T18:16:38.000Z

aighes:

Noch eine Anmerkung zu osmupdate: Wäre es möglich den Update-Server einzustellen?

Kennst du einen Mirror, der genauso aktuell ist wie der originale Server? Einbauen könnte man das sicherlich.

aighes:

Ich hab mir MinGW von nuwen geholt, damit hat das -o3 leider nicht geklappt. Hat jemand eine Idee, woran das liegen könnte?

Fast alle Linux-lastigen Programme unterscheiden zwischen Groß- und Kleinbuchstaben. Probierst bitte mal mit -O3

aighes · 2011-10-17T18:58:52.000Z

gwdg ist nur ein paar Stunden hinterher…das würde mir schon reichen von.

Ich hab mit O3 und o3 probiert…

wicking · 2011-10-17T19:04:51.000Z

kellerma:

<

<member type="node" ref="31165489" role="location_hint 	"/>

Oh, und ist jedenfalls was ganz unterschiedliches. Das ist ja ein echt schwerer Fehler. Also entweder diese Emulationsvariante ganz entfernen, oder richtig machen.

kellerma · 2011-10-17T19:31:07.000Z

Oh, keine Sorge, ich hab’ noch mehr:

<

  <bounds minlat="48.83289" minlon="9.906651" maxlat="49.78804" maxlon="11.60161"/>

<

<tag k="source" v="Bing"/>

Marqqs · 2011-10-17T21:04:44.000Z

aighes:

gwdg ist nur ein paar Stunden hinterher…das würde mir schon reichen von.

Gib mir bitte mal den Link, ich find ihn nicht mehr.

edwin-ldbg · 2011-10-17T21:15:53.000Z

Der schlimmste Fehler ist, dass diese OSM Dateien alle in Englisch sind.

aighes · 2011-10-17T22:24:37.000Z

ftp://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/

kellerma · 2011-10-18T13:41:11.000Z

Hi,

ich schneide Nürnberg aus Mittelfranken aus, einmal “direkt”:
$ osmconvert -B=polygon.62780.poly mittelfranken.osm.pbf > Nürnberg.osm
und einmal “via pbf”:
$ osmconvert -B=polygon.62780.poly mittelfranken.osm.pbf --out-pbf > Nürnberg.pbf
$ osmconvert Nürnberg.pbf > Nürnberg.pbf.osm

Scheinbar bleiben aber bei der “pbf-Varianet” die BBOX von Mittelfranken erhalten:
$ diff Nürnberg.pbf.osm Nürnberg.osm
3c3
<

  <bounds minlat="49.33142" minlon="10.98824" maxlat="49.5418" maxlon="11.28253"/>

Ciao,
Frank

Marqqs · 2011-10-18T16:51:50.000Z

aighes:

ftp://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/

Danke! Mit osmupdate Version 0.2A nun erledigt. Die Option heißt “–planet-url=” und ist im Hilfetext beschrieben. Mit “–planet-url=mirror” kriegst du den gwdg.de-Mirror.
Leider ist der nur eingeschränkt zu empfehlen. Ich weiß nicht, wann dort der Updateprozess läuft, die Sync-Reihenfolge der einzelnen Dateien ist jedenfalls ungünstig. Beispiel:

ftp://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/hour-replicate/state.txt

Dort steht, dass das die neueste hourly-Datei die Sequenz-Nummer 16731 hat. Diese Datei wird von osmupdate aber nicht gefunden, weil sie nicht existiert. Die tatsächlich vorhandene neueste Datei hat die Nummer 16730.

Marqqs · 2011-10-18T17:10:36.000Z

kellerma:

Hi,

ich schneide Nürnberg aus Mittelfranken aus, einmal “direkt”:
$ osmconvert -B=polygon.62780.poly mittelfranken.osm.pbf > Nürnberg.osm
und einmal “via pbf”:
$ osmconvert -B=polygon.62780.poly mittelfranken.osm.pbf --out-pbf > Nürnberg.pbf
$ osmconvert Nürnberg.pbf > Nürnberg.pbf.osm

Scheinbar bleiben aber bei der “pbf-Varianet” die BBOX von Mittelfranken erhalten:
$ diff Nürnberg.pbf.osm Nürnberg.osm
3c3
<
  <bounds minlat="49.33142" minlon="10.98824" maxlat="49.5418" maxlon="11.28253"/>
Ciao,
Frank

Wow, was dir alles auffällt. Danke! Das hatte ich echt übersehen. Gefixt mit Version 0.4A, grad hochgeladen.

misterboo · 2011-10-23T10:52:40.000Z

Hallo,

Ich konnte jetzt nichts genaues finden im Thread hier …

Wie sind bisher die Testergebnisse zum pbf Format ?

Bei mir funktioniert es nicht. Ich verwende allerdings nicht osm2pgsql sondern imposm zum Einlesen der pbf Datei in die DB.

osm2pgsql liest die mit osmconvert erstellte pbf Datei, imposm allerdings nicht.

Wenn ich die mit osmconvert erstellte pbf Datei wieder mit osmosis konvertiere mit

osmosis --rb test.pbf --wb test-neu.pbf

dann kann imposm die Datei lesen.

Beim Konvertieren ist dann die osmosis pbf Datei etwas größer als die osmconvert pbf Datei.

Update: ich kenne mich leider mit dem pbf Format nicht so aus, es scheint aber mit der granularity zu tun zu haben.
osmosis schreibt wohl einen default Wert von 100 in die pbf Datei und dieses Wert sucht imposm dann.

Bei der osmconvert pbf Datei scheint imposm diesen granularity Wert nicht zu finden.

Marqqs · 2011-10-23T12:22:58.000Z

misterboo:

Wie sind bisher die Testergebnisse zum pbf Format ?

Bei mir funktioniert es nicht. Ich verwende allerdings nicht osm2pgsql sondern imposm zum Einlesen der pbf Datei in die DB.

osm2pgsql liest die mit osmconvert erstellte pbf Datei, imposm allerdings nicht.

Hallo!

Bis jetzt gibt es noch nicht viele Feldversuche mit den von osmconvert erzeugten .pbf-Dateien. Nach allem, was ich bisher sagen kann, entsprechen die .pbf-Dateien aber genau dem Standard, der auf der OSM-Wiki-Seite https://wiki.openstreetmap.org/wiki/PBF definiert ist. Das heißt, ich würde einen Fehler in der Importschnittstelle von Imposm nicht ausschließen. Ebenso wenig kann ich natürlich einen Fehler in osmconvert ausschließen.

Welche Fehlermeldung gibt denn Imposm aus?

misterboo · 2011-10-23T12:35:37.000Z

ich habe mein Post gerade upgedatet, kannst du damit was anfangen (granularity Wert)

Marqqs · 2011-10-23T13:07:01.000Z

misterboo:

Update: ich kenne mich leider mit dem pbf Format nicht so aus, es scheint aber mit der granularity zu tun zu haben.
osmosis schreibt wohl einen default Wert von 100 in die pbf Datei und dieses Wert sucht imposm dann.

Bei der osmconvert pbf Datei scheint imposm diesen granularity Wert nicht zu finden.

Das ist richtig, osmconvert schreibt diesen Wert nicht. Es handelt sich um einen DEFAULT-Wert, Imposm sollte sich also nicht darauf verlassen, dass der optionale Wert auch in der Datei enthalten ist. Aus der PBF-Formatdefinition:

  // Granularity, units of nanodegrees, used to store coordinates in this block
  optional int32 granularity = 17 [default=100];

Hast du Kontakt zu den Imposm-Entwicklern? Der Fehler ist sicher relativ leicht zu beheben.

misterboo · 2011-10-23T13:13:33.000Z

Marqqs:

misterboo:

Update: ich kenne mich leider mit dem pbf Format nicht so aus, es scheint aber mit der granularity zu tun zu haben.
osmosis schreibt wohl einen default Wert von 100 in die pbf Datei und dieses Wert sucht imposm dann.

Bei der osmconvert pbf Datei scheint imposm diesen granularity Wert nicht zu finden.

Das ist richtig, osmconvert schreibt diesen Wert nicht. Es handelt sich um einen DEFAULT-Wert, Imposm sollte sich also nicht darauf verlassen, dass der optionale Wert auch in der Datei enthalten ist. Aus der PBF-Formatdefinition:
  // Granularity, units of nanodegrees, used to store coordinates in this block
  optional int32 granularity = 17 [default=100];
Hast du Kontakt zu den Imposm-Entwicklern? Der Fehler ist sicher relativ leicht zu beheben.

Nein … ich werde aber mal einen Bug Report erstellen auf der imposm Seite

Den Fehler behoben habe ich schon in imposm, indem ich einfach die betreffende Abfrage nach dem granularity Wert geändert habe und nun der default Wert von 100 genommen wird falls kein anderer Wert in der pbf Datei angegeben ist.