Hallo,
in letzter Zeit bekomme ich beim updaten des planets immer folgende Fehlermeldung:
Could not get 183500800 bytes of memorie. Dann bricht er das mergen der diffs ab.
Ich betreibe das ganze mit dem fertigen win32 exe auf einem Win7 64bit mit ausreichend Speicher. Ich hab es auch schon mal mit mingw selber compiliert, hat aber auch nichts genutzt. Mit mingw64 komme ich nicht wirklich klar.
Kann mir einer beim compilieren von den beiden Tools für Win64 helfen? Welche Dateien muss ich dafür herunterladen und wie muss ich das dann compilieren? Evtl. auch optimiert für einen Phenom II X6.
Oder hat einer eine andere Idee, woran es sonst noch liegen könnte?
Hallo,
also bei mir funzt das unter WIN7-64 Ultimate mit folgenden Aufruf
.\osmup.exe --planet-url=http://planet.openstreetmap.org/redaction-period/ --hourly --daily --emulate-osmosis --keep-tempfiles -v -b=%box% %osm% lausitz.pbf
osmupdate.exe sollte ja umbenannt werden bei mir in osmup.exe steht so auf der Herstellerseite
die Variablen %box% enthält folgendes == set box=13.6,50.6,15.5,51.3
und Variable %osm% == set osm=europe.osm.pbf
Programm habe ich auch nur von der Herstellerseite runtergeladen, und bis vor zwei Stunden haute das auch alles noch hin.
Gruß AlterSachse
Jetzt hab ich ein --daily ergänzt, da läuft er durch. Wo ich bisher dachte, er bekommt für die großen Dateien nicht genug RAM. Als in der redaction-Zeit mal nur minutly verfügbar war, ist er auch durchgelaufen. Werde mal weitere Kombinationen testen.
Gemeine Falle! Bei allen Programmen die “update” im Namen haben, ‘denkt’ Windows, es müsse sich um ein Programm in bestimmter Struktur für Updates von Programmen handeln.
Das ist im Fall von osmupdate natürlich nicht gegeben. Daher kommt diese Reaktion. Abhilfe ist zum Glück trivial: Osmupdate einfach umbennenen ohne “update” im Programmnamen (z.B. “osmupd”). Disclaimer: Kenne ich nur aus dem Forum, hat aber seinerzeit wohl geholfen.
Der Rechner ist mit Windows 10 ausgestattet, hat 8GB RAM und das ganze läuft in einer OSGeo4W-Shell, was aber auch nur eine cmd.exe am Ende ist. Es scheint ja alles zu funktionieren, es steht ja schliesslich “osmupdate: Completed successfully.” da, aber ein wenig befremdlich ist das schon. Ich belasse die Dateien ja im PBF-Format wegen späterer Weiterverarbeitung, liegt es evt. daran?
Hallo Frank,
die betreffende Meldung wird von osmconvert ausgegeben, wenn zum Einlesen einer Datei Speicherplatz angefordert, aber vom Betriebssystem nicht zur Verfügung gestellt wurde.
Verwendest du die 64-Bit-Version von Windows 10? Falls ja, wurde das Programm osmconvert für 64 oder für 32 Bit übersetzt?
Zur Fehlersuche:
osmconvert wird von osmupdate aufgerufen. Die betreffenden Systemaufrufe werden angezeigt, wenn du statt “-v” die Option “-v=2” übergibst. Vielleicht bringt das noch etwas Licht ins Dunkel…
Ja, ich habe die 64bit Version von W10, osmconvert ist die 32bit, die im Wiki verlinkt ist. Das ganze passiert übrigens nicht, wenn man das o5m-Format nimmt, die Meldung kommt nur mit pbf als Format. Ich teste die ausführlichere Ausgabe und poste die Ausgabe, sobald mich die Grippe mal länger als 10 Minuten an den Rechner lässt …
Gibts inzwischen Neuigkeiten zu dem Thema?
Unter Windows 10 funktioniert mit pbf und osmupdate und osmconvert alles zuverlässig. Auf meinen Servern mit Windows Server 2008 reproduzierbar nicht. Dort gibt es den could not get bytes of memory Fehler. (erst seit einigen Monaten)
Und ja, der Server hat reichlich Arbeitsspeicher übrig, 185 MB sind eigentlich kein Ding.
Blöd: Die Datei wird trotzdem geschrieben, sie hat aber eine andere Größe als die gleiche Datei unter Windows 10 upgedated.
Insbesondere fehlen Multipolygone, der Rest scheint ok zu sein.
Ich hab mir mal den osmosis.c Code besorgt und die Stelle angeschaut, ist unspektakulär.
Bei einem solchen Fehler sollte die Datei besser nicht geschrieben werden statt eine unvollständige zu schreiben.
Ich wollte osmconvert mal unter Windows und Visual Studio compilieren, aber mir scheinen ein paar Header zu fehlen, wo bekommt man die?
