osmconvert schreibt PBF

aighes · 2011-10-16T21:25:34.000Z

Edwin, denk doch an die armen Bäume…

wicking · 2011-10-16T22:38:09.000Z

Weiter geht’s mit der Analyse.

Da ich die Binärdaten nicht lesen kann (war zu kurz in der Matrix, oder so) nur die OSM-Dateien.

Die OSM-Dateien aus Osmosis verwenden Tabs (= 1 Byte) zur Einrückung. Die aus osmconvert je zwei Leerzeichen (= 2 Byte) statt einem Tab. Somit könnten die OSM-Dateien aus osmconvert größer sein, sind sie aber nicht.

Außerdem stehen bei Osmosis die Angaben für lat=… lon=… ganz am Ende, bei osmconvert ganz am Anfang nach der id. Bei osmosis ist die Reihenfolge uid, user, changeset, bei osmconvert aber changeset, uid, user.

Dann gibt’s auch noch ein paar wenige Sonderzeichen, die osmosis als benannte Entitäten (z.B. ") ausgibt, osmconvert aber als dezimale Entitäten (z.B. ").

Seltsamerweise gibt osmconvert im Gegensatz zu osmosis natürliche Zahlen mit einem abschließenden Punkt an. So:
„34."
statt nur
„34"

Das alles kann man rausfiltern bzw. umstellen, die Dateien also „normieren". Dann sind sich die Dateien schon viel ähnlicher und eher vergleichbar. Habe das mit sed gemacht.


for i in iran.osm.{1,2,3,4}; do
  sed -i -e 's%\ \ %%g' -e 's%\t%%g' -e 's%\ uid="0"\ user=""%%' -e 's%\(.*\ \)\(id="[0-9]\+"\)\(.*\)\(\ lat="[0-9\.]\+"\ lon="[0-9\.]\+"\)\(.*\)%\1\2\4\3\5%' -e 's%\(.*\ id="[0-9\.]\+"\)\(.*\)\(\ changeset="[0-9]\+"\)\(.*\)%\1\3\2\4%' -e 's%\&%\&%g' -e 's%\'%\'%g' -e 's%\"%\"%g' -e 's%\>%\>%g' -e 's%\<%\<%g' -e 's%\
%\
%g' -e 's%\
%\
%g' -e 's%\(.*l[ao][tn]="[0-9]\+\)\(\."\)\(.*\)%\1"\3%g' $i
done

Dabei ist mir aufgefallen, das ziemlich häufig CarriageReturn und LineFeed in Werten vorkommt. Schrecklich! Das muss wohl versehentlich (copy&paste) passiert sein, sollte aber mal durch einen Bot behoben werden. Da verschluckt sich doch sicher so manches Programm dran. Naja, kann man auch einfach als Leerzeichen interpretieren, und wenn’s ein Bot repariert, sind die Fehler sicher bald eh wieder irgendwo drin.

Als Ergebnis erhalte ich, dass alle vier Dateien iran.osm.{1,2,3,4} bis auf die Zeilen 2 und 3 identisch sind. In Zeile 2 steht der Name des erstellenden Programms, in Zeile 3 stehen die Außenränder („bounding box"), welche Unterschiedlich angegeben sind.

Jetzt gilt es andere Bereiche oder gleich die ganze Welt zu vergleichen. Und dann noch Boundingboxes, Boundingpolygone und andere komplexe Dinge zu vergleichen. Dies könnte das osmconvert ebenfalls aus dem Tritt bringen.

kellerma · 2011-10-16T22:52:17.000Z

wicking:

Die OSM-Dateien aus Osmosis verwenden Tabs (= 1 Byte) zur Einrückung. Die aus osmconvert je zwei Leerzeichen (= 2 Byte) statt einem Tab. Somit könnten die OSM-Dateien aus osmconvert größer sein, sind sie aber nicht.

Nö, es ist genau umgekehrt:
osm-Dateien - von osmconvert generiert - benutzen zur Einrückung je einen Tabstop,
osm-Dateien - von osmosis - hingegen 2 spaces pro Einrückungstiefe
=> (hauptsächlich) deshalb sind die osm@osmosis-Dateien auch größer.

Der Datenvergleich geht auch Quick ‘n’ Dirty:
osm2pgsql -s iran.osmconvert.osm
pg_dump gis > iran.osmconvert.osm.sql
osm2pgsql -s iran.osmosis.osm
pg_dump gis > iran.om.osmosis.sql
md5sum *.sql

Ciao,
Frank

Marqqs · 2011-10-17T10:22:15.000Z

kellerma:

Nö, es ist genau umgekehrt:
osm-Dateien - von osmconvert generiert - benutzen zur Einrückung je einen Tabstop,
osm-Dateien - von osmosis - hingegen 2 spaces pro Einrückungstiefe
=> (hauptsächlich) deshalb sind die osm@osmosis-Dateien auch größer.

Stimmt. Das war mit ein Grund, warum ich bei der Tab-Variante geblieben bin.

Hat einer von euch mal die osmconvert-Option –emulate-osmosis probiert? Zwar ist die nicht perfekt, aber die dann noch notwendigen Nacharbeiten wären sicher viel einfacher.

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.