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.
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)
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”.
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.
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:
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.
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.
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.
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.
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).
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, …
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)
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.
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.
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.
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.
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.
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.
