Auf den Download-Seiten von Geofabrik (http://download.geofabrik.de/openstreetmap/) finden sich nur noch kleine Dateien zwischen 100 und 200 Bytes (jawohl: Bytes, nicht Megabytes), momentan alle von gestern nacht.
Was ist da passiert? Haben wir die 32bit-Grenze bei den Node-IDs schon überschritten, aber die Geofabrik-Software kann das noch nicht? Oder andere Ursachen?
Das werden wir dann wissen, wenn sich Frederik Ramm (aka woodpeck) [oder Jochen Topf] zu Wort gemeldet hat:
http://forum.openstreetmap.org/viewtopic.php?pid=311730#p311730
also hessen und rl-pfalz gehen bei mir wieder - gestern waren die leer. aber nur die .osm.pbf
Gruss
walter
Hallo,
Ich habe, als ich den Fehler bemerkte, schnell ein paar aeltere Dateien hinkopiert, damit wenigstens irgendwas da ist, und die dann sukzessive durch neu berechnete ersetzen lassen. Die Neuberechnung ist durch, aber die bz2 hinken noch hinterher, die sind aber in der Mache.
Grund fuer das Problem war peinlicherweise die 64bit-ID-Geschichte, vor der ich ja ca. seit einem halben Jahr gewarnt habe und die ich deswegen eigentlich ohne Zwischenfall haette ueberstehen sollen 
Irgendwann in den naechsten Tagen kann ich hoffentlich auch die “OSM-Extrakte Next Generation” freischalten. Dabei wird es die folgenden Aenderungen geben:
- zusaetzlich ein “north-america.osm.pbf”
- zu jedem .pbf auch diejenigen der letzten paar Tage
- zu jedem .pbf auch Osmosis-/osmupdate-kompatible taegliche “diffs”, so dass man sich mit sehr geringer Bandbreite sein germany.osm.pbf (o.ae.) aktuell halten kann
- zu jedem .pbf das passende .poly
- etwas uebersichtlichere Verzeichnis-Ansicht (mit Minikarte usw.)
Die URLs fuer bz2/zip/pbf-Files bleiben gleich, allerdings kann es sein, dass sie zu einem redirect fuehren (germany.osm.pbf auf germany-latest.osm.pbf oder so).
Bye
Frederik
Ich hätte da noch einen kleinen Vorschlag: wie wäre es noch mit zusätzlich einem DACH (inkl Südtirol)-Extrakt?
Ich denke, da könnte sicher Interesse darin bestehen, sodass man oftmals statt des europa-Extraktes, “nur” das DACH herunterladen würde - das könnte noch ein bisschen Bandbreite sparen.
Ich glaub aber beim osmupdate bzw. eher osmconvert muß auch wegen der 64-bit Geschichte nachgebessert werden!
Ich bekomme da auch seit einigen Tagen “uint32 Memory Overflow” (Sowas hatte ich schonmal - aber da war igenend eine Daly-Diff zerschossen die den Fehler erzeugt hatte.).
Diff-Quelle ist : http://planet.openstreetmap.org/replication/day/000/000/
die übliche für osmupdate!
osmupdate bzw. osmconvert ist natürlich die aktuellste
Hallo Frederik,
gäbe es dann auch noch bei den OSM-Downloads nach Regionen die Chance, einige bisher nicht abgedeckte Staaten wie z.B. Thailand noch mit aufzunehmen?
Denn mir fiel auf, dass die vielleicht allseits bekannte Android-App Osmand bzw. dessen eigener Kartenserver für **bestimmte ** Regionen in der Welt die OSM-Rohdaten nicht von geofabrik.de, sondern von download.cloudmade.com bezieht.
siehe https://github.com/osmandapp/OsmAnd-tools/blob/master/obf-generation/regions/full_indexes.xml
Die Rohdaten von Cloudmade sind aber sehr veraltet, laut webseite mit Stand Dezember 2011!!!
Gibt es evtl. technische oder Kapazitätsgründe, warum bestimmte Staaten derzeit nicht von geofabrik.de angeboten werden?
Stephan
Ich denke nicht das es eine 64-bit Geschichte ist, ich habe so eine Fehlermeldung häufiger für die unterschiedlichsten Länder, meistens USA. Ich tippe eher auf ein generelles PBF-Format-Interpretations-Problem.
Thorsten
Hallo zusammen,
ich bekomme bei osmosis mit den aktuellen osm Dateien von Geofabrik (Stand heute) Fehlermeldungen:
“Cannot represent 2147500687 as an integer.”
Das Problem tritt seit heute auf. Vorher lief alles bestens.
Ich benutze osmosis 0.41. Da sollte eigentlich das Problem mit der 64 bit Geschichte behoben sein.
Liegt es an den Dateien von Geofabrik oder an osmosis?
Marcel
----------GELÖST-------------
Nach einiger Recherche habe ich das Problem gelöst. Die Dateien von Geofabrik sind OK. Es liegt an osmosis: http://wiki.openstreetmap.org/wiki/64-bit_Identifiers
Dank an Geofabrik für die schnelle Reaktion!
Könnte es sein, daß während der Problemphase der Datenabgleich nicht ordentlich funktionierte? Z.B Weg #204964625 (http://www.openstreetmap.org/browse/way/204964625), der mit Ausnahme von 2 Punkten nur aus neuen Nodes mit IDs jenseits der 2^31 besteht, am Sonntag von mir angelegt.
Wenn ich mit dem Oberpfalz-Extrakt vom 12.Februar meine Garmin-Loipenkarte erstelle, fehlt diese Loipe stets. Ich habe bereits splitter auf 283 und mkgmap auf 2484 upgedated - neuester Stand.
Ich versuche, nur Laender anzubieten, die auch oefters als einmal die Woche nachgefragt werden (sonst ist die Herstellung im Vergleich zum Nutzen zu aufwendig - irgendwas jeden Tag wieder auszurechnen und ungesehen wegzuwerfen ist halt schad drum). Aber Thailand wird oefters gefragt, das sollte ich echt mal hinzufuegen.
Bye
Frederik
Es wäre doch sicher möglich, die Aktualisierungsfrequenz entsprechend herabzusetzen. Bei Ländern, nach denen Nachfrage zwar vorhanden, aber eher gering ist, wäre etwa ein wöchentlicher Extrakt gegenüber der jetzigen Situation schon eine enorme Verbesserung.
Eventuell könnte man das Aktualisierungsintervall sogar dynamisch anhand der täglichen Abrufe anpassen.
Wäre es möglich Österreichische Bundesländer anzubieten? Ich versuche die von mir benötigten Regionen immer klein zu halten, aber ich generiere manchmal eine Garminkarte für Bayern und Tirol und lade dafür immer Bayern und ganz Österreich runter, merge diese dann und schneide von Österreich das meiste weg (mit osmconvert). Gäbe es Tirol einzeln, müßte ich nicht immer ganz Österreich runterladen nur um dann wieder das meiste auszuschneiden.
Außerdem hätte ich auch Interesse an etwas “exotischeren” Ländern (wie etwa Grönland). Dafür würde es aber reichen wenn die Daten einmal im Monat aktualisiert werden. Täglich muß gar nicht sein.
Gruß
unixasket
Hi Frederik,
danke für deine Mühe aber irgendwie fehlt mir was:
exemplarisch: http://www.openstreetmap.org/browse/way/205227804 am Dienstag Nachmittag (12.2.13) neu angelegt -natürlich mit “neuen” Nodes- und andere Sachen in dieser Ecke kann ich in hessen.osm.pbf vom 13.2. 4:38 nicht finden.
Komisch ist halt, dass sich der Timestamp geändert hat aber anscheinend alte Daten drin sind. Könnte eventuell an der Umstellung liegen, die du gerade machst.
Jetzt checke ich mal germany.osm.pbf - aber das kann dauern.
EDIT: Hat gedauert: sind dort auch nicht drin - planet.osm spar ich mir (und meinem Rechner) mal. Eventuell ist es morgen besser.
Gruss
Walter
Ich habe das Problem mit den neuen Nodes weiter analysiert und meine Analysen Geofabrik zukommen lassen: die neuen Nodes scheinen in den Extrakten zu fehlen.
Ziemlich deutlich zu sehen beim Vergleich des Screenshots einer Garmin-Karte, die ich heute angefertigt habe (http://berniesmaps.de/QLandkarte-Korkuteli.png), mit Openstreetmap (http://www.openstreetmap.org/?lat=37.06393&lon=30.20736&zoom=15&layers=M).
Wenn ich Daten über JOSM runterlade und abspeichere, kann ich daraus mit splitter (Version 283) und mkgmap (Version 2337 oder 2484) Karten erstellen, die die neuen Nodes enthalten.
Nahmd,
Über das Tages- oder Stunden-Diff sind die bei mir angekommen.
Way 205227804
Version: 1
Tags:
addr:city = Wiesbaden
addr:country = DE
addr:housenumber = 8a
addr:street = Sundgaustraße
building = residential
~user = wambacher
Enthält:
Pos Node Lon Lat Info Also used in
1 2038577447 8.190440 50.051196 193351800
2 2152011134 8.190457 50.051154
3 2152011133 8.190303 50.051130
4 2038577446 8.190287 50.051172 193351800
5 2038577447 8.190440 50.051196 193351800
Sollten also wohl im Planet enthalten sein?
Gruß Wolf
Ich halte es auch für sinnvoll, mehr Regionen anzubieten, diese aber nicht täglich zu aktualisieren.
Wer täglich aktuelle Daten benötigt, der kann einfach OSMUpdate aufrufen und hat die Daten für seine Lieblingsregion innerhalb weniger Minuten auf aktuellem Stand.
Wer einmal eine andere Region (z.B. für einen Urlaub) benötigt, dem ist es wohl meistens egal, ob die Daten eine Woche alt sind oder von gestern.
Walter
Die Länder auf die ich am häufigsten angefragt werde sind: Russia - asiatischer Teil, Thailand, South Korea (neben Russland asischer Teil übrigens das einzige fehlende G20 Land), Hong Kong, Macau.
Auch ab und zu angefragt, und immerhin unter den doch noch recht populären Reiseländern fehlt derzeit:
Tunisia, Zimbabwe, Botswana, Jordan, Peru, Paraguay, Colombia, Venezuela.
Cuba und Dominican Republic wird auch immer wieder angefragt, aber Mittelamerikaextrakt ist noch recht klein in OSM Daten (bzw auch Höhenlinien), also braucht es IMHO keine eigene Kubakarte. Asien, Afrika und Südamerika sind dagegen einfach zu groß (OSM Daten Kontinent, wie auch SRTM Höhenlinien).
Ich habe grade aus den Geofabrik Extrakten eine neue Garminkarte für Oberbayern gebaut und die enthält alle Wege die ich seit dem Wochenende eingetragen habe nicht. Ich habe am Sonntag abend mehrere Waldwege eingetragen und die fehlen alle. Der Extrakt hat aber das Datum 13.02.13.
Wegen des Kommentars von Walter: Ich würde zu Mappingzwecken zumindest die Mitteleuropäischen Extrakte (Deutschland, Österreich, etc.) gerne weiterhin Tagesaktuell haben, aber exotischere Regionen können gerne nur wöchentlich aktualisiert werden.
Gruß
unixasket
Klar, in meiner DB hab ich die natürlich auch.
SOLLTEN wohl - aber sind sie? Wenn die Morgen nicht in den Extrakten auftauchen, werde ich mir den Planet mal besorgen und greppen. Das einzig sichere ist, dass sie in der OSM-DB und in den Diffs drin sind, aber selbst der Planet ist bereits davon abgeleitetet - also “Ware 2. Wahl”
Gruss
walter
p.s. kennt jemand ein Programm Postgresql-DB im Snapshot-Format → osm XML-Format? dann mach ich mir meine Extrakte halt selber.
Ist nämlich irgendwie blöd: Einerseits hab ich eine Live-DB von DACH+ (minütliche Updates) und andererseits lade ich Extrakte runter um damit Osmand-Daten zu erstellen.