Error-Meldung bei osmupdate.exe

Bei meinem letzten Update meiner europe.osm.pbf hat osmupdate folgende Fehlermeldung ausgespuckt:

Error: PBF write: uint32 memory overflow

Ich nehme an das int32 mit 4.294.967.295 (oder –2,147,483,648 to 2,147,483,647) an seine Grenzen gekommen ist!

Gibt es die möglichkeit die osmupdate aufzubohren (int64).
Komm bitte aber nicht kannst du selber: C++ = Buch mit 7 Siegeln !!!

Kompilliere mit mingw64 oder gibts die osmupdate.exe korrigiert schon fertig für 64Bit kompilliert??

Hallo!
Die Meldung sagt schon, was es vermutlich ist: der Speicher ist zu knapp. Wie viel Arbeitsspeicher hast du zur Verfügung?
Versuch bitte mal, den Platzbedarf von osmupdate (eigentlich osmconvert, es wird von osmupdate aufgerufen) zu reduzieren: Option --max-merge=

Kann aber auch sein, dass die Ursache woanders liegt. Ist der Fehler reproduzierbar? Welche Dateien sind beteiligt?

An dem vermuteten 31-Bit-Problem kann es eher nicht liegen, beide Programme verwenden schon das “große” Format.

Kann es etwas mit der Änderung für osmosis/splitter zutun haben?

Am Hauptspeicher kann wohl nicht liegen win7-64Bit und 16GB Hauptspeicher.
Das Problem hatte ich wie ich die europe.osm.pbf mit insgesamt 7 Day-Diffs (update nach 7 Tage) - reproduzierbar.
Am nächsten Tag nochmal updatet (1 Diff) da hatte ich keine Fehlermeldung!
Ich werd mal max-merge ausprobieren vielleicht löst es das Problem!

Beteiligt sind die üblich Programme : osmupdate, osmconvert (Beide für win + 64Bit kompilliert) wget und europe.osm.pbf.

Edit:
-max-merge= und --max-days= hab ich ausprobiert immer noch die Fehlermeldung.

Die Fehlermeldung kommt erst wenn die PBF erstellt wird (und daa erst wenn diese etwa 400-500MB groß ist (europe.osm.pbf ca 8GB)) - das merge in eine Datei (jetzt ca. 235 MB groß) geht ohne Fehler.

Hallo mal eine Frage am Rande: Wie compiliert man das speziell für Win 64bit?

In dem man z.B. mingw64 die entsprechenden parameter mitgibt:

z.B.

c:\mingw64\bin\gcc.exe osmconvert.c -lz -m64 -march=corei7-avx -O2 -pipe -o osmconvert.exe

ist für mein System das optimum.

Da ist aus der europe.osm.pbf innerhalb von 4min ein Ausschnitt erstellt (allerdings geht bei > 2Gb kein complex-way bzw. complet-way nicht)

Tritt der Fehler mit den vorkompilierten 32-Bit exe’s auch auf ?

Ist genau das selbe nachdem die neue pbf ca 400MB groß kommt die Fehlermeldung (3mal), die pbf wird aber weiter erstellt…

Hast du eine einzelne Datei für mich, die beim Umwandeln mit osmconvert solche Fehlermeldungen bringt? Ich würde dem Fehler dann gezielt nachjagen…

Ich Update normalerweise nur die europe.osm.pbf.

Und die Fehlermeldung kommt leider nur beim Updaten, schneiden mit dem selben osmconvert geht problemlos.

Extrakte der europe.osm.pbf (france germany usw.) erzeugen beim Updaten keine Fehlermeldung??

Wenn bei anderen da Updaten der europe.osm.pbf ohne Fehler geht muß meine europe.osm.pbf einen schlag weghaben.

Hallo,

ich bekomme jetzt die Fehlermeldung auch, und zwar auf einem 64bit Linux System mit 8GB Arbeitsspeicher. Allerdings nicht mit osmupdate, sondern mit osmconvert.

Der Fehler tritt erst auf, seitdem ich mein immer selbst geupdatetes planet file gelöscht habe und durch das neue ODbL planet File ersetzt habe, welches ich mit osmosis 0.41 update.
Sie tritt auf, wenn ich versuche die USA aus dem Planet File auszuschneiden.
Die osmconvert Version ist egal.

Ich kann das Problem auf mehreren Rechnern mit unteschiedlicher Konfiguration reproduzieren.
Die Meldung kommt genau 3x.

Irgend etwas, mit dem ich helfen kann das zu debuggen?

Thorsten

Wenn ich mich dunkel erinnere, werden pro Fehlerbild max. bis zu 3 Fehler ausgegeben,
kann also gut sein, dass der Fehler selbst zweihundert mal passierte.

Kannst Du mal den genauen Befehlszeilenaufruf posten, damit andere dass nachvollziehen koennen?

Ich habe in den letzten Tagen versucht eine Anweisung zu erstellen, ohne mein upgedates Planet-File zur Verfügung stellen zu muessen. Leider hat das nicht so ganz geklappt. Es tritt wohl nur auf, wenn man mit osmosis mehrmals das planet file updated, aber es tritt nicht auf wenn man von 0 auf heute in einem Schritt geht …

Aber hier jetzt trotzdem mein osmconvert Aufruf:

osmconvert data/planet/planet.osm.pbf -B=osmmaps/scripts/poly/usa.poly --drop-author --drop-version --drop-broken-refs --out-pbf -o=usa.osm.pbf

Mein usa.poly kann hier gefunden werden: http://osm.thkukuk.de/tmp/usa.poly

Thorsten

Hallo Thorsten, danke für deine Mühen! Leider ist es halt schwer bis unmöglich, den Fehler zu finden, wenn man ihn nicht selber reproduzieren kann. Deine Befehlszeile ist in Ordnung, einzig das “–drop-broken-refs” könnte problematisch sein. Es führt zwar nicht zu einem Fehler, aber es wäre theoretisch möglich, dass du Punkte eines Wegs nicht mehr automatisch in diesen hineinbekommst, wenn sie jemand von außerhalb nach innerhalb deines ausgeschnittenen Bereichs schiebt und dabei das Wegobjekt selbst nicht verändert.

Zum osmupdate-Fehler: vielleicht tritt er wirklich nur im Zusammenhang mit Osmosis auf? Vielleicht liegt das Problem in der Interpretation des PBF-Formats. Hier ist es wichtig, dass du von allen beteiligten Programmen die neuesten Versionen verwendest.

Falls der Fehler trotzdem wieder auftritt, würden mich die Input-Dateien interessieren, damit ich auf die Jagd gehen kann. :slight_smile:
Falls die Dateien zu groß sind und du keine Möglichkeit hast, sie über einen Server zum Download zur Verfügung zu stellen, bleibt noch der Weg per CD per Post.

Grüße
Markus

Oder Ihr trifft Euch auf halbem Weg am Laufertorturm zu einem Bierchen :wink:

Hallo,

ok, ein Weg das einigermassen verläßlich zu reproduzieren:


osmosis --read-replication-interval workingDirectory=tmp --simplify-change --write-xml-change tmp/changes.osc.gz
osmosis --read-xml-change file=tmp/changes.osc.gz --read-pbf file=planet-120912.osm.pbf --apply-change --write-pbf file=tmp/planet.osm.pbf omitmetadata=true
osmconvert tmp/planet.osm.pbf -B=usa.poly --drop-author --drop-version --drop-broken-refs --out-pbf -o=tmp/usa.osm.pbf

Eventuell muessen die osmosis Kommandos mehrmals ausgeführt werden, der Fehler tritt nicht immer auf, aber sobald er einmal aufgetreten ist, bleibt er.

Ich verwende von allen die allerneusten Versionen, aber das erste Mal trat es auch mit älteren osmosis sowie osmconvert Versionen auf. Ich denke auch es gibt da irgendwo einen Unterschied, wie etwas zu interpretieren ist.

Markus, Deinen Kommentar über --drop-broken-refs verstehe ich nicht, das dürfte doch nur eine Rolle spielen, wenn die Daten upgedated werden, aber ich verwende osmconvert nur zum Ausschneiden, danach werden sie nie mehr upgedated.

Thorsten

Ich könnte ja fiess sein und sagen dann update doch nicht mit osmosis! :roll_eyes:

Aber es darf ja jeder es so machen wie man will!
Ich habe aber so das Gefühl das der Fehler von osmosis verursacht wird wenn der Updateintervall zu kurz ist.
Und osmconvert halt empfindlicher reagiert als osmosis - oder bringt osmosis mit entsprechender Datei auch den fehler?

osmupdate (im prinzip osmconvert [das ja das eigentliche Update macht]) bringt/brachte (nicht mehr überprüft) ein Fehler wenn ich an einem Tag 2*Updaten wollte (allerdings nur Tagesupdate).

Ich hab da auch gleich nee Frage!

Für was braucht man --drop-broken-refs ??

Das schneidet doch Way usw. aus dem Bereich raus - da fehlen mir doch am rand lauter Wege und Flächen!!!
Ich hab nur Verwendung für das umgekehrte --complex-ways - ich will ja auch am Rand möglichst alles und wenn nötig wegen der Darstellung auch darüber hinaus!

Stimmt, ich glaub, wir hätten wirklich nicht weit. :slight_smile:

Werd ich mal testen, muss aber zuerst ein aktuelles Osmosis ziehen. Natürlich muss es mit Osmosis funktionieren, aber quasilottes Frage ist berechtigt: Warum nimmst du nicht einfach osmupdate?


--> statt der beiden Osmosis-Aufrufe:
osmupdate -v tmp/planet_alt.o5m tmp/planet_neu.o5m --hour --day --drop-author
--> statt deines osmconvert-Aufrufs:
osmconvert tmp/planet_neu.o5m -B=usa.poly --drop-broken-refs -o=tmp/usa.osm.pbf

OK, da hast du natürlich Recht, in dem Fall kannst du schneiden wie du willst.

Der Plattenplatz auf der Kiste mit der schnellen Internetverbindung reicht für o5m Dateien nicht, und mit pbf ist osmupdate nicht schneller als die beiden osmosis Aufrufe zusammen. Deshalb: Never change a running system :wink:

Übrigens finde ich es unglücklich die Ausgabe von --help auf stderr auszugeben, das macht ein lesen von osmupdate --help |less unnötig kompliziert.

Thorsten

welch Zufall, dieses ist mir vorgestern auch aufgefallen:
$ osmupdate --help 2>&1 | less
:wink:

EDIT:
Wem’s nicht gefällt, kann’s - open source sei Dank - selbst patchen:


--- osmupdate.c 2012-09-21 20:05:59.000000000 +0200
+++ osmupdate.c.new     2012-09-21 20:07:00.000000000 +0200
@@ -1101,7 +1101,7 @@
       fprintf(stderr,"osmupdate Parameter: %.2000s\n",a);
     if(strcmp(a,"-h")==0 || strcmp(a,"-help")==0 ||
         strcmp(a,"--help")==0) {  // user wants help text
-      fprintf(stderr,"%s",helptext);  // print help text
+      fprintf(stdout,"%s",helptext);  // print help text
         // (took "%s", to prevent oversensitive compiler reactions)
 return 0;
       }