Hallo Peter,
'ne ganz schön große Kiste
Ich denke, vielleicht ist die Zeit reif für ein paar Gedanken wie wir da
"etwas mehr Ordnung reinkriegen". Klar geht das nicht in ein paar Tagen
- aber ein Anfang wäre damit gemacht.
Zwischenschritt in der Pipeline, die das OSM-Universum bildet:
Ja, das klingt nach einem seehr guten Plan!
Eine noch zu lösende Aufgabe wird es sein, den Prozess so offen zu
gestalten, dass es jederzeit möglich bleibt, die Core-DB (bzw. deren
Spiegel) auch "am Standard-Prozess vorbei" beliebig zu nutzen.
Ein Standard-Prozess kann aber gefühlt 80..98% aller Aufgaben abdecken.
Ich könnte mir das so vorstellen:
Mapper > E-Verarbeitungsschicht > DB > A-Verarbeitungsschicht > Anwendung
Die Daten des Mappers (1)
werden von einem intelligenten Editor entgegengenommen und
vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2).
In der Eingangsverarbeitung werden die Daten der verschiedenen Editoren
standardisiert aufbereitet und in die Core-DB geschrieben (3).
Aus der DB werden in der Ausgangsverarbeitung verschiedene Schichten
(standardisierte Views) generiert(4),
auf die die Anwendungen zugreifen (5).
Eine dieser Views ist ein Spiegel der Daten von 3. Auch die anderen
Views kann man beliebig spiegeln, um schnellen Zugriff zu gewährleisten.
In der Ein- und Ausgangsvearbeitung gibt es dann:
Ansätze:
- weiter so taggen, dass die Renderer, die bereits existieren,
damit ohne Änderungen umgehen können
und damit die Datenbank entsprechend begrenzen,
- oder man setzt eben bei den Renderern selbst
- oder zwischen Renderern und Datenbank an.
Ich würde letzteres bevorzugen.
Ich auch.
Gruss, Markus
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
