osmconvert schreibt PBF

kellerma · 2011-10-16T20:41:30.000Z

wicking:

Also etwa so:


mkfifo bla{1,2}
for ((i=1; i<=1000; i++)); do
  (head -n -$((100*$i)) | head -n 100 > bla 1) &
  (head -n -$((100*$i)) | head -n 100 > bla2) &
  colordiff bla1 bla2
done

Interessantes Konzept, da fehlen wohl noch die Dateien, also z. B.


  (head -n -$((100*$i)) iran.oc.osm | head -n 100 > bla1) &
  (head -n -$((100*$i)) iran.om.osm | head -n 100 > bla2) &

Und damit kommen wir schon zur Kernfrage: Was willst Du denn vergleichen?

Für die aufeindander generierten pbf von osmconvert genügt md5sum, denn wenn sich die hashes unterscheiden,
liegt bereits ein Fehler vor.

Die pbf von osmosis mit den pbf von osmconvert: Hat Markus schon erklärt, dass sie unterschiedlich “gepackt” werden.

Die osm von osmosis mit den osm von osmconvert: Hier zeigen schon die ersten 4 Zeilen, dass die unterschiedlich sind:
a) osmconvert hat einen anderen "generator="String
b) osmconvert benutzt Tabs statt zweier Leerzeichen beim osmosis
c) Die Abfolge der key/values innerhalb der node/way/relation ist unterschiedlich
=> Alle Zeilen (außer der ersten) sind unterschiedlich.

Du muesstest erst die Inhalte normalisieren und kann (color)diff nicht leisten.

wicking · 2011-10-16T20:45:57.000Z

kellerma:

Interessantes Konzept, da fehlen wohl noch die Dateien, also z. B.
(head -n -$((100*$i)) iran.oc.osm | head -n 100 > bla1) &
(head -n -$((100*$i)) iran.om.osm | head -n 100 > bla2) &

Ja, die habe ich vergessen.

Und damit kommen wir schon zur Kernfrage: Was willst Du denn vergleichen?
=> Alle Zeilen (außer der ersten) sind unterschiedlich.
Du muesstest erst die Inhalte normalisieren und kann (color)diff nicht leisten.

Genau. Ich will die OSM-Dateien vergleichen, um fehlende oder falsch übersetzte Elemente zu finden. Dazu muss man sie normalisieren, was mit sed (oder perl) ganz fix geht. Ergebnisse folgen.

edwin-ldbg · 2011-10-16T21:13:36.000Z

Meine Programmiersprache nenne ich E+³ 4D

Genau. Ich will die OSM-Dateien vergleichen,

Hast keinen Drucker?

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