On Tue, Sep 25, 2007 at 04:29:58PM +0200, Sascha Silbe wrote:
Nachdem ich jetzt ein paar Stunden (puh!) damit verbracht habe, ein wenig auf [EMAIL PROTECTED] zu lesen, hier ein paar Ergänzungen:
Ich stelle mir da vor, daß der API-Server von jeder Transaktion (0.5 kann doch Transaktionen/Changesets, oder?) ein Diff (ähnlich den Diffs zum Planet-File) erstellt, signiert und zum Verteilen weiterreicht.[1] suggeriert, daß auch 0.5 _keine_ ChangeSets kennt. Damit wird ein "echtes" Realtime-Update unmöglich, da wir nicht für jeden einzelnen Node eine EMail verschicken wollen. Man könnte zwar die Änderungen zusätzlich in einer Tabelle speichern und daraus dann einmal pro Minute ein Diff erzeugen. Aber den Aufwand ists IMO nicht wert, stattdessen sollte man lieber auf ChangeSets in der API hinarbeiten.
- API reicht Änderungen in Rohform an einen Daemon, der daraus ein Diff erstellt und signiert per Mail verschicktDa in naher Zukunft keine Transaktionen unterstützt werden (dürfte eine größere Änderung sein), würde ich das - wie schon von anderen geplant - durch einen regelmäßigen Aufruf von Osmosis [2] zum Erzeugen des Diffs ersetzen. Ein kleiner Wrapper könnte die erzeugte Datei signieren und per Mail verschicken.
- Diff und Sig als Mail-Attachment an eine Mailingliste verschicken (1 Liste pro 10°-Block)Statt 10°-Block würde ich hier eine QuadTile-ID [3] fester Länge benutzen. Die grundlegende Idee der QuadTiles (wenn auch der Name IMO nicht passt) ist ziemlich gut und wurde auch in dem Peer2Peer-Netz CAN [4] benutzt, für das ich als Projekt zu ner Vorlesung mal ne Implementierung machen musste. Lustigerweise musste ich genau daran denken, als ich von den Problemen mit der Indizierung der Tabellen gelesen habe (erst danach habe ich die Wiki-Seite zu den QuadTiles gelesen).
- jedes Diff enthält die ID (Timestamp?) des alten und des neuen Zustands - Dumps (Planet-File) enthalten ebenfalls die ID des Zustandes, den sie enthalten
Das fällt dann wohl flach.
1. Änderung der API, so daß die Änderungen an den Diff-Daemon weitergereicht werden
Entfällt.
2. Schreiben eines Daemons, der die Änderungen im Rohformat entgegennimmt und daraus eine PGP/MIME-Mail erzeugt und (per /usr/lib/sendmail) an den lokalen MTA weiterreicht. Empfängeradresse ist <prefix>-<tileID>@<domain> (z.B. [EMAIL PROTECTED])Wird ersetzt durch: Schreiben eines Wrappers für osmosis, der das Diff signiert und per EMail verschickt.
4. Schreiben eines Tools, das die per EMail gelieferten Diffs auf Gültigkeit prüft (PGP-Sig, ID), ggf. zwischenspeichert (Reihenfolge-Änderungen sind bei EMail möglich) und auf die Datenbank anwendet.Wird ersetzt durch: Schreiben eines Wrappers für osmosis, der die Attachments extrahiert, die PGP-Sig überprüft und osmosis auf das Diff anwirft.
6. Ändern (oder Neuschreiben) des Tools, das die Planet-Files erstellt (Aufteilen in 10°-Blöcke).Wenn ich das richtig verstanden habe, kann osmosis mit mehreren Ausgabe-Dateien umgehen. D.h. man könnte entweder bereits auf dem DB-Server mehrere Dateien erzeugen (dazu müsste dann dort osmosis statt planet.c laufen) oder den Planet-Dump auf einem anderen Rechner in Stücke teilen (dann bräuchte der DB-Server nur planet.c laufen lassen => weniger Last).
Das OsmChange-Format [5], das Osmosis verwendet, sieht geeignet aus. Zustands-IDs gibts derzeit eh nicht => keine Erweiterung nötig.Sobald man sich auf ein Format für die Diffs geeinigt hat,
Damit ist das sogar relativ kurzfristig machbar (nur ein paar Wrapper und ein kleines Tool schreiben sowie ein paar Mailinglisten aufsetzen). Die Frage ist jetzt: Macht das so Sinn für alle Beteiligten? Für meine eigenen Zwecke wärs jedenfalls sehr geschickt, auch wenn ich dafür Sun Java, noch dazu die 1.6 (die bei Debian etch nicht dabei ist), auf meinem Server installieren müsste. Aber ist das auch für die anderen so geeignet? Direkt auf die Daten greifen ja vermutlich nur wenige zu, die meisten werden irgendwelche gerenderten Tiles verwenden.
[1] http://wiki.openstreetmap.org/index.php/OSM_Protocol_Changes_V0.4_to_V0.5
[2] http://wiki.openstreetmap.org/index.php/Osmosis [3] http://wiki.openstreetmap.org/index.php/QuadTiles [4] http://en.wikipedia.org/wiki/Content_Addressable_Network [5] http://wiki.openstreetmap.org/index.php/OsmChange CU Sascha -- http://sascha.silbe.org/
pgp2kUGRpX1ck.pgp
Description: PGP signature
_______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
