1001

Schaut man sich die täglichen Statistiken auf odbl.de an, dann sieht man, dass täglich rund 1 - 1,5 mio Nodes erstellt und geändert werden.

1002

Das ist mir schon klar^^ Es geht mir zunächst einmal nur darum einen groben Überblick zu bekommen, wie viel nach der Lizenzumstellung neu erfasst werden muss. Nicht mehr und nicht weniger.

1003

@SunCobalt:
Kannst Du auch noch mal die ganzen “special request stats” laufen lassen? Bei denen braucht man ja nun wahrlich kein wöchentliches Update, aber jetzt nach den beiden Mailaktionen wär’s schon nett zu sehen, was sich da jeweils getan hat (und danach vielleicht sogar regelmäßig in größeren Abständen, z.B. alle 4-6 Wochen?).

Wäre eventuell auch was für geomaniX: entweder wicking (aber der scheint gerade nicht da zu sein) oder aighes fragen, dann kriegst Du auch so eine hübsche (?) Tabelle für die Region Deiner Wahl.

1004

okay, sobald world durch ist, stosse ich special mal an.

1005

Prima, vielen Dank.

1006

hat Geofabrik eigentlich ein Downloadlimit? Durch das Nachholen von Nordamerika, World und die Specials (die Asien und Afrika Extrakte beinhalten), lade ich diese Woche sehr viel runter (world, aber das kommt von gwdg, Extrakte aller möglichen Länder, Bundesländer, Europa, Afrika, Asien etc.)

1007

Ich hab mal ein paar Wochen lang täglich germany.osm.bz2 runtergeladen und wurde nicht gesperrt. Aber sozial war das nicht; hab dann umgestellt auf tägliche Updates per Changefile. Würde ich in deinem Fall wahrscheinlich auch machen. Ist viel weniger Traffic.

1008

Hattest Du auch eine feste IP?
Das Thema hatte ich mit wicking mal. Es wäre ja nicht nur Germany sondern europa oder world, was aktuell gehalten werden müsste. Es würde weniger Traffic bedeuten, klar. Andererseits müsste bei jeder Berechnung dann europe oder world durchsucht werden, selbst wenn nur Island berechnet wird. Wicking hat eine Art Zwitter installiert, teils Extraxte, teils lokal aktuell gehaltene File. Aber ich habe sein System nur mit den Extrakten durchschaut. Und Bandbreite habe ich 100MBit Downstream. Da ist ein Download wesentlich schneller als wenn man für jede Statistik world oder europe durchsuchen müsste.

1009

Ja, das war von einem Internet-Server aus. Aber frag doch Frederik einfach mal direkt, er kann dir sicher sagen, wie viel Traffic noch ok ist und ab wann es Probleme gibt.

Im Fall des Daily Changefiles hast du zwei Möglichkeiten: Entweder du updatest das World-File und schneidest dann die Extrakte wieder alle aus, oder du updatest alle Extrakte einzeln. Bei der zweiten Möglichkeit musst du trotzdem das jeweilige Polygon anwenden, weil sonst neue Nodes in der Datei landen, die gar nicht in der jeweiligen Region liegen.

Bei der Datenbasis für opengastromap.de und openptmap.de läuft das nach diesem Schema:
http://wiki.openstreetmap.org/wiki/Daily_update_an_OSM_XML_file

Wenn du statt osmchange das neuere Programm osmconvert nimmst und als Datenformat nicht .osm.gz, sondern .o5m, dann sollte das um einiges schneller laufen. Wär vielleicht einen Versuch wert.

Naja, der Server von Geofabrik begrenzt die Downloads sowieso auf ca. 2 MB/s (16 Mbit/s).

EDIT: Muss mich korrigieren, manchmal schnellt die Geschwindigkeit auf 3 bis 4 MB/s hoch. War mir bisher nicht aufgefallen.

1010

Naja, ich habe da so meine Zweifel, dass ein aktuell halten von 30-50 verschiedenen Extrakten so effektiv ist. Aber bald ist ja wicking wieder da, der hat im Gegensatz zu mir Ahnung von sowas.

Und jetzt nochmal ganz blöd gefragt, da ich weiß, dass es auch andere interessiert. Mit dem Schema lassen sich lokal begrenzte Daily Diffs einspielen, ob nun File oder DB?

1011

Obs effektiv ist, weiß ich auch nicht. Aber es sollte wohl nicht ewig dauern. Vielleicht sogar schneller als die Downloads.

Die Strategie, die ich verlinkt hab, bezieht sich nur auf Dateien, nicht auf eine Datenbank. “Lokal begrenzte Diffs” bringen übrigens nichts, man muss immer das komplette Diff nehmen und dann den Output entsprechend beschneiden. Grund: Diffs enthalten auch Ways und Relations, nicht immer sind dann deren Knoten dabei, so dass die geografische Zuordnung oft im Dunkeln bleibt.

1012

Vielen Dank. Im Moment kann ich es nicht brauchen. Ich weiß aber, dass ich es brauchen werde und in der Vergangenheit mal genau nach so einer Lösung gesucht habe. Ich werde mich bald mal genauer damit beschäftigen.
Nur eins ist mir nicht klar. Du schreibst “Die Strategie, die ich verlinkt hab, bezieht sich nur auf Dateien, nicht auf eine Datenbank. “Lokal begrenzte Diffs” bringen übrigens nichts, man muss immer das komplette Diff nehmen und dann den Output entsprechend beschneiden.”
Kann der Output nicht auch wieder ein Diff sein? Denn dann könnte man mit Diff->lokales Diff->DB auch eine lokale DB updaten

1013

Ja, technisch geht das schon, aaaber. :wink:

Beispiel: In deiner Region wird nur ein Straßenname geändert. Das Diff-File sieht dann z.B. so aus:

<osmChange>
<modify>
  <way version="2">
    <nd ref="123"/>
    <nd ref="456"/>
    <tag k="name" v="Bahnhofstraße"/>
  </way>
</modify>
</osmChange>

(Nicht schimpfen über mögliche Syntaxfehler, habs schnell ausm Kopf zusammengetippt.)

Wie du siehst, sind zu den Knoten nur die Referenzen und keine Koordinaten enthalten, das heißt, aus der Datei lässt sich nicht erkennen, ob der Weg innerhalb oder außerhalb deiner Region liegt. Um das festzustellen, brauchst du die Komplettdatei der Region. Und dann kannst du grad so gut die Diff-Datei auf die Regin-Datei anwenden und das Ergebnis neu zuschneiden, das ist auch nicht mehr Rechenaufwand. osmconvert kann das sowieso in einem Aufwasch.

Hoffentlich hab ich das jetzt klarer ausgedrückt… :slight_smile:

1014

Special ist durch, zusätzlich sind die Länder und wichtigen Städte aus AT in special drin. Auf speziellen Wunsch ist auch die Antarktis auf der Hauptseite drin (das war eher ein Versehen und wird nicht regelmäßig aktualisiert)

@Marqqs wicking macht das ganze programmieren. Wenn er wieder da ist, kommt er bestimmt mal auf Dich zu. Ich verstehe zwar Deine Erläuterungen, aber irgendwie umsetzen in Perl oder so kann ich es nicht. Ich bin sozusagen der Notbetrieb.

1015

world ist jetzt auch wieder da, allerdings als planet-latest. Ich habe keine Möglichkeit gefunden den Namen zu ändern (versucht habe ich es schon, aber es klappt nicht). Aber zumindest ist world jetzt wieder da

1016

Thomas, Geofabrik hat ein Downloadlimit, wie jeder finanzierbare Server auch. Ich glaub, das liegt bei 6TB Traffic im Monat, dann wird die komplette Speed gedrosselt. Daher wäre es durchaus sinnvoll, dass man sich den Planeten holt und selber schneidet. Alleine schon im Interesse der anderen Nutzer, die auch Extrakte laden wollen.

Und wenn man das Schneiden mit einem flotten Tool macht, dauert es auch nicht arg lange.

1017

Die Funktion ist nun auch in Potlatch 2 freigeschaltet worden.

Wenn man auf “Optionen” klickt, gibt es die Moeglichkeit “Show license status” anzuklicken. Wenn ich es richtig erkenne, werden dann alle Objekte die einen “problematischen” Status mit Bezug auf den Lizenzwechsel haben farbig hinterlegt.

1018

Von der Geschwindigkeit mit osmchange ist der Vorgang sehr flott. Ich aktualisiere täglich meine Extrakte und habe diese mit gzip -1 schwach komprimiert. Ungefähr folgende Zeiten brauche ich dazu am Server:

~3min aktualisieren des austria+ Extrakts inclusive entpacken und Packen via pipe (577MB hat der mit gzip -1 komprimiert)
~15min aktualisieren meines germany+ Extrakts inclusive entpacken und Packen via pipe (3363MB hat der mit gzip -1 komprimiert)

Markus

1019

Genau, dieses Verfahren ist eingespielt und läuft auch recht zuverlässig.

Interessant wär es zu wissen, ob es mit osmconvert schneller geht. Denn dann könnte man sich das Aus- und Einpacken der lokalen Dateien sparen, weil sie im .o5m-Format etwa die gleiche Größe haben (evtl. sogar kleiner?) und viel schneller verarbeitet werden können.

Natürlich müsste man am Ende dann doch noch einmal packen, nämlich wenn man das Ergebnis als .osm.gz zum Download anbieten will.

Hat das schon jemand getestet? Falls nicht, müsste ich das einfach mal probehalber laufen lassen…

1020

Ähm, also ich würde es gut finden, wenn man “data reduction” deaktivieren könnte, um sich erstmal auf die “(possible) data loss” konzentrieren zu können. Sonst wird man ja vor Meldungen erschlagen. Und anfangen würde ich erstmal mit den wichtigen “data loss”