Geofabrik: keine brauchbaren Dateien verfügbar

Das werden wir dann wissen, wenn sich Frederik Ramm (aka woodpeck) [oder Jochen Topf] zu Wort gemeldet hat:
http://forum.openstreetmap.org/viewtopi … 30#p311730

kellerma wrote:

Das werden wir dann wissen, wenn sich Frederik Ramm (aka woodpeck) [oder Jochen Topf] zu Wort gemeldet hat:
http://forum.openstreetmap.org/viewtopi … 30#p311730

also hessen und rl-pfalz gehen bei mir wieder - gestern waren die leer. aber nur die .osm.pbf
Gruss
walter

Hallo,

wambacher wrote:

kellerma wrote:

Das werden wir dann wissen, wenn sich Frederik Ramm (aka woodpeck) [oder Jochen Topf] zu Wort gemeldet hat:
http://forum.openstreetmap.org/viewtopi … 30#p311730

also hessen und rl-pfalz gehen bei mir wieder - gestern waren die leer. aber nur die .osm.pbf
Gruss
walter

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

woodpeck wrote:

Hallo,

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"
  

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.

woodpeck wrote:

• 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
  

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/replica … y/000/000/
die übliche für osmupdate!
osmupdate bzw. osmconvert ist natürlich die aktuellste

woodpeck wrote:

Hallo,

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.)
  

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-too … ndexes.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

quasilotte wrote:

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/replica … y/000/000/
die übliche für osmupdate!
osmupdate bzw. osmconvert ist natürlich die aktuellste

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.

stephan75 wrote:

Gibt es evtl. technische oder Kapazitätsgründe, warum bestimmte Staaten derzeit nicht von geofabrik.de angeboten werden?

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

woodpeck wrote:

Ich versuche, nur Laender anzubieten, die auch oefters als einmal die Woche nachgefragt werden ...

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.

woodpeck wrote:

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.

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

woodpeck wrote:

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.

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.06 … 5&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,

wambacher wrote:

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.
[...]
EDIT: Hat gedauert: sind dort auch nicht drin - planet.osm spar ich mir (und meinem Rechner) mal.

Ü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

Netzwolf wrote:

Über das Tages- oder Stunden-Diff sind die bei mir angekommen.

Klar, in meiner DB hab ich die natürlich auch.

Sollten also wohl im Planet enthalten sein?

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.

Walter Schlögl wrote:

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.

Hallo Walter, woodpeck

+1

Wöchentliche Updates scheinen mir für viele Regionen durchaus ausreichend. Damit kann man die zusätzliche Last auf sieben Tage verteilen. Je nach Anzahl der Downloads kann man auch auf einen Zwei-Wochen oder monatlichen Rythmus runter gehen.

Bei der Aussage "kann einfach OSMUpdate aufrufen" wollte ich zuerst Protest rufen. Bei genauerer Überlegung geht es jedoch um Leute, die sich Geofabrik-Extrakte ziehen und daraus eigene Karte für Garmin oder Online bauen. Für diese Leute dürfte OSMUpdate in der Tat kein Problem sein.

Edbert (EvanE)

Wöchentliche Updates für außerhalb Europa, würde wohl wenige stören. Aber die Updates dann bitte alle 7 Tage zur gleichen Zeit. Dann kann man sich drauf einstellen. Mittwoch wäre etwa ein guter Tag. Sprich wenn spätestens Donnerstag Mittag alle Karten up to date sind, hat man als "Kartenersteller" genug Zeit für Freitag die Updates einzuspielen/bereitzustellen - womit User am Wochenende, bzw ab Freitag für die Wochenendplanung aktuelle Karten haben.

extremecarver wrote:

guter Tag. Sprich wenn spätestens Donnerstag Mittag alle Karten up to date sind, hat man als "Kartenersteller

extremecarver wrote:

Wöchentliche Updates für außerhalb Europa, würde wohl wenige stören. Aber die Updates dann bitte alle 7 Tage zur gleichen Zeit. Dann kann man sich drauf einstellen. Mittwoch wäre etwa ein guter Tag. Sprich wenn spätestens Donnerstag Mittag alle Karten up to date sind, hat man als "Kartenersteller" genug Zeit für Freitag die Updates einzuspielen/bereitzustellen - womit User am Wochenende, bzw ab Freitag für die Wochenendplanung aktuelle Karten haben.

die wenigsten user werden sich jedes wochenende neue karten erstellen. klar ist es gut zu wissen, wann man aktuelle daten erhält aber der rest ist blödsinn (meine Meinung)

Jayjay01 wrote:

die wenigsten user werden sich jedes wochenende neue karten erstellen. klar ist es gut zu wissen, wann man aktuelle daten erhält aber der rest ist blödsinn (meine Meinung)

Ich erstelle mir wöchentlich eine neue Garminkarte und zwar für Mappingzwecke. Das allerdings nur für ein Bundesland oder einen Regierungsbezirk.

Gruß
unixasket

stellvertretend_für_viele wrote:

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.

Ja, und ich hätte neben den Vatikan auch noch gerne Hintertupfingen-Land, aber bitte nur alle 8,33 Tage (ausgenommen Ostern und chinesisches Neujahr, versteht sich!).

Hey Leute,
kommt mal wieder ein bischen runter von Euren "Ich_wünsch_mir_was_aber_zackzack".

Das ist ja schon fast peinlich 🙁

Zu Wunschextrakten: Es gibt auch noch den Service auf:
http://extract.bbbike.org/
Da lassen sich Extrakte beliebiger Regionen erstellen. Aber: Leider sieht man nirgends von wann die Daten sind. Für exotische Regionen ist das aber die Alternative zu den Geofabrik Extrakten. Wegen der Aktualität werde ich europäische Länder aber weiterhin von Geofabrik holen.

Achja und zwecks überzogen: Es sind lediglich Wünsche die geäußert wurden. Ob die dann umgesetzt werden hängt von denen die es machen ab. Äußern darf man ja Wünsche, man sollte nur nicht erwarten das diese dann auch alle umgesetzt werden (von jemand anderen und kostenlos dazu!). Ich habe selber auch schon Sachen kostenlos ins Netz gestellt. Ich reagiere dann auch auf Wünsche von Nutzern, aber das heißt nicht das ich die dann alle umsetze, manchmal aber schon.

Gruß
unixasket

wambacher wrote:

SOLLTEN wohl - aber sind sie? Wenn die Morgen nicht in den Extrakten auftauchen, werde ich mir den Planet mal besorgen und greppen.

Hi,
ich hab mal wieder die Extrakte geprüft und es fehlen immer noch "meine" Daten. Dann wollte ich mich wie versprochen an den Planet ranmachen , hab dann aber ein wenig gestutzt:

http://planet.openstreetmap.org/planet/2013/

planet-130213.osm.bz2␣␣␣␣␣␣␣␣␣14-Feb-2013␣02:11␣␣␣18G
planet-130206.osm.bz2␣␣␣␣␣␣␣␣␣09-Feb-2013␣16:11␣␣␣26G
planet-130130.osm.bz2␣␣␣␣␣␣␣␣␣02-Feb-2013␣05:14␣␣␣25G
planet-130123.osm.bz2␣␣␣␣␣␣␣␣␣25-Jan-2013␣23:36␣␣␣25G
planet-130116.osm.bz2␣␣␣␣␣␣␣␣␣18-Jan-2013␣23:23␣␣␣25G
planet-130109.osm.bz2␣␣␣␣␣␣␣␣␣12-Jan-2013␣01:53␣␣␣25G
planet-130102.osm.bz2␣␣␣␣␣␣␣␣␣05-Jan-2013␣05:08␣␣␣25G
...

Wieso ist das Teil seit einigen Tagen kleiner geworden? Und gleich um 8 GB?

Gruss
walter

Nachtrag: ich schätze mal, dass es was mit 64-Bit zu tun hat und hab mal auf talk nachgefragt.
und nop auf dev 🙂

unixasket wrote:

Aber: Leider sieht man nirgends von wann die Daten sind.

Wenn ich es richtig in Erinnerung habe, dann wird einmal pro Woche der neue Planet heruntergeladen, aus welchem dann die Extrakte erstellt werden:
http://download.bbbike.org/osm/planet/

Aktuell ist das planet-130206.osm.bz2, also Daten vom 6. Februar.

Gruß,
Mondschein

wambacher wrote:

planet-130213.osm.bz2␣␣␣␣␣␣␣␣␣14-Feb-2013␣02:11␣␣␣18G
planet-130206.osm.bz2␣␣␣␣␣␣␣␣␣09-Feb-2013␣16:11␣␣␣26G

Wieso ist das Teil seit einigen Tagen kleiner geworden? Und gleich um 8 GB?

Sehr gute Frage - ich hab sie mal auf der Developer Mailingliste gestellt, nachdem dort noch nichts dazu zu finden war.

Allerdings erklärt das vom Datum her noch nicht wo Deine Daten geblieben sind, das Planetfile wurde ja erst heute morgen erstellt. Die Verkleinerung kann aber gut die selbe Ursache haben falls OSM wirklich einen Datenverlust um 31% erlitten hat.

bye, Nop

Mondschein wrote:

Wenn ich es richtig in Erinnerung habe, dann wird einmal pro Woche der neue Planet heruntergeladen, aus welchem dann die Extrakte erstellt werden:
http://download.bbbike.org/osm/planet/

Aktuell ist das planet-130206.osm.bz2, also Daten vom 6. Februar.

Die Extrakte auf der Geofabrik werden täglich aktualisiert. Das würde keinen Sinn machen, wenn der Input dafür nur wöchentlich kommt. Das tatsächliche Verfahren kenne ich nicht, müßte aber dann aber wohl über die inkrementrellen Updates stattfinden die es minütlich, stündlich oder täglich gibt.

bye, Nop

Nop wrote:

Allerdings erklärt das vom Datum her noch nicht wo Deine Daten geblieben sind, das Planetfile wurde ja erst heute morgen erstellt. Die Verkleinerung kann aber gut die selbe Ursache haben falls OSM wirklich einen Datenverlust um 31% erlitten hat.

man könnte sich ja auch noch die diffs ansehen - aber ehrlich gesagt, hab ich keine grosse Lust dazu. Wenn es wirklich ein Problem sein sollte, müssen sich die richtigen Leute drum kümmern.
Leider hab ich noch keinen aktuellen Planet auf meinem Rechner, weil der Download trotz meiner 50 Mbit-Leitung ätzend lange dauert, da ja der Sender die Speed bestimmt. (ca 8H statt geschätzter 2H)

Ich werde mich wohl mal um die Alternative (Postgresql --> PolyFilter --> xml-File) kümmern müssen.

Gruss
walter

wambacher wrote:

Wenn es wirklich ein Problem sein sollte, müssen sich die richtigen Leute drum kümmern.

Für alle, die bei der Developer-Liste nicht mitlesen:

Grand Slater wrote:

Known now. I have removed the broken planet.osm export. The planetdump
code failed due to integer overflow. Will be fixed up shortly.
Next planet.osm will likely be next week now.

Nun denn

Gruss
walter

Nop wrote:

wambacher wrote:

planet-130213.osm.bz2␣␣␣␣␣␣␣␣␣14-Feb-2013␣02:11␣␣␣18G
planet-130206.osm.bz2␣␣␣␣␣␣␣␣␣09-Feb-2013␣16:11␣␣␣26G

Wieso ist das Teil seit einigen Tagen kleiner geworden? Und gleich um 8 GB?

Sehr gute Frage - ich hab sie mal auf der Developer Mailingliste gestellt, nachdem dort noch nichts dazu zu finden war.

Allerdings erklärt das vom Datum her noch nicht wo Deine Daten geblieben sind, das Planetfile wurde ja erst heute morgen erstellt. Die Verkleinerung kann aber gut die selbe Ursache haben falls OSM wirklich einen Datenverlust um 31% erlitten hat.

bye, Nop

Noch besser sieht es bei den pbf's aus - da ist nur noch rund 20% übrig (von 19GB auf 4,1GB).

Ist definitiv das 64bit-Problem - da das vorherige (auch latest) von 6.2 ist (erstellt am 9.2) und die neuste planet.osm.pbf vom 13.2.

schaun mer mal wann wieder alles in Butter!
Ich wart immernoch darauf wann osmconvert (osmupdate) wieder ohne uint32-Fehler updatet - irgendwo in den diffs muß auch noch was sein (vielleicht auch nur in einer bzw. in welchen die noch mit den 64bit-Problem erstellt wurden).

quasilotte wrote:

Ich wart immernoch darauf wann osmconvert (osmupdate) wieder ohne uint32-Fehler updatet - irgendwo in den diffs muß auch noch was sein (vielleicht auch nur in einer bzw. in welchen die noch mit den 64bit-Problem erstellt wurden).

kannst ja ausnahmsweise osmosis verwenden. Trotz aller Gerüchte schafft der das durchaus.

Es gibt einen Sonderfall:

wiki wrote:

Recent versions (in particular, the current version 0.41) will work in most cases, with the following exception: the options --used-node or --used-way will, in general, fail, unless the additional option idTrackerType=Dynamic is supplied.

Also, wenn du die Optionen --used-node und/oder --used-way verwendest, mußt du zusätzlich idTrackerType=Dynamic angeben, dann sollte es klappen.

Gruss
walter

Nop wrote:

Mondschein wrote:

Wenn ich es richtig in Erinnerung habe, dann wird einmal pro Woche der neue Planet heruntergeladen, aus welchem dann die Extrakte erstellt werden:
http://download.bbbike.org/osm/planet/

Aktuell ist das planet-130206.osm.bz2, also Daten vom 6. Februar.

Die Extrakte auf der Geofabrik werden täglich aktualisiert. Das würde keinen Sinn machen, wenn der Input dafür nur wöchentlich kommt.

Ich antwortete auf:

unixasket wrote:

Zu Wunschextrakten: Es gibt auch noch den Service auf:
http://extract.bbbike.org/
Da lassen sich Extrakte beliebiger Regionen erstellen. Aber: Leider sieht man nirgends von wann die Daten sind. Für exotische Regionen ist das aber die Alternative zu den Geofabrik Extrakten.

BBBike.org verwendet nicht die Extrakte der Geofabrik, sondern direkt den Planeten.
Würde keinen Sinn ergeben, erst die Geofabrik-Extrakte herunterzuladen und diese dann wieder zusammenzufügen und dann daraus wieder Extrakte zu erstellen... 🙂
Nur zur Info:
Bei BBBike.org kann man sich Wunschextrakte erstellen lassen, von einem beliebigen Gebiet (so lange es nicht zu groß ist).
BBBike.org extrahiert dann die Daten aus dem Planeten und konvertiert diese dann auf Wunsch z.B. nach Mapsforge, Shapefile, OsmAnd, ...

Gruß,
Mondschein

wambacher wrote:

Es gibt einen Sonderfall:

wiki wrote:

Recent versions (in particular, the current version 0.41) will work in most cases, with the following exception: the options --used-node or --used-way will, in general, fail, unless the additional option idTrackerType=Dynamic is supplied.

Also, wenn du die Optionen --used-node und/oder --used-way verwendest, mußt du zusätzlich idTrackerType=Dynamic angeben, dann sollte es klappen.

Wie ich inzwischen mit Brett klären konnte [1], ist diese Aussage noch unvollständig/mißverständlich.

Das Problem ist, daß der idTrackerType=BitSet bei >32bit IDs abraucht. D.h. man darf bei Osmosis diesen Tracker nicht nutzen, egal welche Version, weder als impliziten Default wie bei den Parametern oben noch explizit angegeben (wie es bei mir der Fall war)

bye, Nop

[1] http://gis.19327.n5.nabble.com/osmosis- … 48734.html

wambacher wrote:

man könnte sich ja auch noch die diffs ansehen - aber ehrlich gesagt, hab ich keine grosse Lust dazu. Wenn es wirklich ein Problem sein sollte, müssen sich die richtigen Leute drum kümmern.
Leider hab ich noch keinen aktuellen Planet auf meinem Rechner, weil der Download trotz meiner 50 Mbit-Leitung ätzend lange dauert, da ja der Sender die Speed bestimmt. (ca 8H statt geschätzter 2H)

Das kleine Planetfile wurde als Integerproblem beim Export diagnostiziert. Damit ist immer noch unklar, warum Deine Daten ihren Weg in die Geofabrik-Extrakte nicht gefunden haben. Ich würde Dich bitten es weiterzuverfolgen, nachdem Du ein nachvollziehbares Problem mit konkreten Daten am Wickel hast.

Wenn auch in der Diff-Updatekette ein (32bit) Problem beim Export oder Import besteht, ist ein Großteil der Datenanwender direkt oder indirekt betroffen - aber hat noch keine Unstimmigkeiten bemerkt. Schreib vielleicht mal Fred direkt an.

Einen lokalen Planet aktuell zu halten habe ich übrigens mal ausprobiert und wieder verworfen. Der Update des Planetfiles mit Tagesdiffs dauert mit osmosis auf meinem Server auch 8h. :-(

bye, Nop

Nop wrote:

Ich würde Dich bitten es weiterzuverfolgen, nachdem Du ein nachvollziehbares Problem mit konkreten Daten am Wickel hast.

geht leider nicht mehr, da alle putten Versionen weg sind und nur das vom 9.2.13 online ist.
mach ich natürlich, wenn etwas neues kommt.

Wenn auch in der Diff-Updatekette ein (32bit) Problem beim Export oder Import besteht, ist ein Großteil der Datenanwender direkt oder indirekt betroffen - aber hat noch keine Unstimmigkeiten bemerkt. Schreib vielleicht mal Fred direkt an.

Netzwolf und auch ich haben keinerlei Probleme mit den Diffs - unsere lokalen Daten sind sauber.
Ist auch logisch, wenn man die Toolchain kennt. Mapnik wird von OSM via Diffs gefüttert und rendert alles Neue tadellos - planet.osm wird durch einen nächtlichen Extrakt der Live-DB erstellt und da klemmt es.

Einen lokalen Planet aktuell zu halten habe ich übrigens mal ausprobiert und wieder verworfen. Der Update des Planetfiles mit Tagesdiffs dauert mit osmosis auf meinem Server auch 8h. :-(

Stell mal auf minütlich um. Dann kommt ein kontinuierlicher Datenstrom rüber, der einen guten Rechner nicht arg belastet. Macht aber nur Sinn, wenn die Box 24h läuft. Ansonsten ist beim Anschalten der Backlog zu gross und dann dauert es halt länger.

Gruss
walter

kukuk wrote:

quasilotte wrote:

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/replica … y/000/000/
die übliche für osmupdate!
osmupdate bzw. osmconvert ist natürlich die aktuellste

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.

Ich habe das mal weiter getestet. Verwendest Du eine der --drop-* Optionen? Bei mir tritt das Problem genau dann auf, wenn ich eine davon verwende. Meine Vermutung: Die größenberechnung paßt dann nicht immer.

Thorsten

wambacher wrote:

Nop wrote:

Ich würde Dich bitten es weiterzuverfolgen, nachdem Du ein nachvollziehbares Problem mit konkreten Daten am Wickel hast.

geht leider nicht mehr, da alle putten Versionen weg sind und nur das vom 9.2.13 online ist.
mach ich natürlich, wenn etwas neues kommt.

Ich dachte Deine Daten fehlen nachvollziehbar in den Extrakten der Geofabrik. Die werden aber nicht aus dem Planetfile erzeugt. Wenn Deine Daten also fehlen kann es sein daß in der Diff-Update-Kette hinter den Extrakten irgendwo der Wurm steckt und Deine Daten gefressen hat. Das wäre es Wert nachzuvollziehen, nicht daß in allen Extrakten immer a bisserl was fehlt.

bye, Nop

Nop wrote:

Die werden aber nicht aus dem Planetfile erzeugt.

Das wäre mir neu, werde es morgen (FR) aber mal checken. Ansonsten verhält sich Frederick auffallend still - ich nehme an, dass er nicht online ist sondern sich irgendwo auf der Welt "rumtreibt" 😉
Gruss
walter

edit: typo

Jayjay01 wrote:

extremecarver wrote:

guter Tag. Sprich wenn spätestens Donnerstag Mittag alle Karten up to date sind, hat man als "Kartenersteller

extremecarver wrote:

Wöchentliche Updates für außerhalb Europa, würde wohl wenige stören. Aber die Updates dann bitte alle 7 Tage zur gleichen Zeit. Dann kann man sich drauf einstellen. Mittwoch wäre etwa ein guter Tag. Sprich wenn spätestens Donnerstag Mittag alle Karten up to date sind, hat man als "Kartenersteller" genug Zeit für Freitag die Updates einzuspielen/bereitzustellen - womit User am Wochenende, bzw ab Freitag für die Wochenendplanung aktuelle Karten haben.

die wenigsten user werden sich jedes wochenende neue karten erstellen. klar ist es gut zu wissen, wann man aktuelle daten erhält aber der rest ist blödsinn (meine Meinung)

Darum geht es nicht. Nur ist das der typische Zeitraum (meine Erfahrung) wo sich User die auch mappen Kartendaten runterladen. Sprich einfach nur ein Vorschlag, für den Tag wo ich wöchentliche Updates am sinnvollsten finde. Das sehr viele User auch mit 6- 12 Monate alten Karten aus OSM zufrieden sind, ist eine ganz andere Geschichte...

wambacher wrote:

p.s. kennt jemand ein Programm Postgresql-DB im Snapshot-Format --> osm XML-Format?

Wei wäre es mit osmosis? 😉 Geht aber nur mit Bounding-Box und nicht mit Polygon.

call␣osmosis␣--read-pgsql␣database="osm"␣user="osm"␣^
--dataset-bounding-box␣left=8.02782593␣bottom=50.07863673␣right=8.18472443␣top=50.16162635␣^
--write-pbf␣file="c:\osm\planet\wambach.osm.pbf"

Christian

brogo wrote:

Wei wäre es mit osmosis? 😉 Geht aber nur mit Bounding-Box und nicht mit Polygon.

Jau stimmt, hätt ich auch drauf kommen können, wo ich doch so in osmosis "verliebt" bin 🙁

Das mit der bbox ist nicht schlimm, einfach ein bp dran hängen.

/opt/install/osmosis-0.41/bin/osmosis␣\
--read-pgsql␣authFile=authFile.txt␣\
--dataset-bounding-box␣left=8.03␣right=8.19␣top=50.17␣bottom=50.07␣completeWays=true␣\
--bounding-polygon␣file=wambach.poly␣completeWays=true␣completeRelations=true␣\
--write-xml␣file=wambach.osm

das ganze mach -für mich- aber nur Sinn bei relativ kleinen Bereichen, da osmosis erst einmal temporäre Tabellen anlegt und da alles reinkopiert. Das geht wohl für nen Landkreis oder Bundesland aber bei mehr wird es wohl eng werden. Dennoch hilft mir das bei meinern Osmand-Daten, die aus 2 Kreisen + Mainz + Wiesbaden bestehen extrem weiter.

Danke und Gruss
Walter

p.s. gerade gecheckt: Wambach braucht 3:36 Minuten. Jetzt mach ich mich mal an "mein" Gebiet ran. Und dann wird der neue Rechner bestellt.

wambacher wrote:

Nop wrote:

Die werden aber nicht aus dem Planetfile erzeugt.

Das wäre mir neu, werde es morgen (FR) aber mal checken.

oops, wenn diese Beschreibung noch stimmt, hast du natürlich recht. Aber komisch ist es dennoch.
Gruss
walter

Nachtrag: Heute sind die -mir- fehlenden Daten im Datafabrik-Extrakt aufgetaucht.

Mit dem Oberpfalz-Extrakt von gestern früh (noch keiner von heute vorhanden) ist die Loipe, die ich am Sonntag eingezeichnet habe und während der Woche vermißte, wieder da.
Geofabrik scheint das Problem gelöst zu haben.
Ein herzliches Danke an die Geofabriker.

kukuk wrote:

Ich habe das mal weiter getestet. Verwendest Du eine der --drop-* Optionen? Bei mir tritt das Problem genau dann auf, wenn ich eine davon verwende. Meine Vermutung: Die größenberechnung paßt dann nicht immer.
Thorsten

Hallo miteinander, genau das wars!

Thorsten hat mir einen sauber reproduzierbaren Fall geliefert, so dass ich den Fehler endlich einkreisen konnte. DANKE!

Dieser Testfall beinhaltete das Planet-File, so dass das Einkreisen eine Weile Gedauert hat – es waren einige Durchläufe notwendig.

osmconvert-Version 0.7P sollte aber nun sauber sein.

Schöne Grüße
Markus

wambacher wrote:

Für alle, die bei der Developer-Liste nicht mitlesen:

Grand Slater wrote:

Known now. I have removed the broken planet.osm export. The planetdump
code failed due to integer overflow. Will be fixed up shortly.
Next planet.osm will likely be next week now.

Ein neuer planet mit 26 GB ist vorhin online gegangen.

Gruss
walter

Wie es aussieht, gibt es immer noch Probleme mit den Geofabrik-Extrakten. Ich sehe das bei der Kontrolle der Wall·E-Bearbeitungen: Einige bearbeitete Objekte sind im Geofabrik-Extrakt immer noch in der Vorgängerversion, etwa 205280618. Betroffen sind nach meiner Beobachtung die Bearbeitungen vom 14. Februar, die in germany.osm nicht berücksichtigt zu sein scheinen.

Nachtrag: Die geänderten Objekte waren im day-Diff enthalten, scheinen aber in den entsprechenden hour-Diffs zu fehlen. Ob nur Wall·E's Bearbeitungen oder auch weitere betroffen sind, weiß ich nicht. Die Geofabrik ist also unschuldig. Die von Wall·E bearbeiteten Objekte werden aber noch einmal zu höheren Versionen befördert und in neuen Diffs nachgereicht, indem ein User addr:country=DE (hilft immer) anhängt; damit löst sich das Problem (in Bezug auf diese Objekte) quasi von selbst.