[Talk-de] Separate Datenbank fuer transiente Daten - OSM-T

[Frederik Ramm]

Hallo,

    ich moechte Euch ein Stueck "Vapourware" vorstellen (d.h. es ist 
derzeit 100% Hirngespinst) und dazu eine Meinung hoeren.

Zunaechst die Vorgeschichte:

Vor ein paar Tagen fuhr ich mit dem Auto eine Strecke, die ich oefters 
zuruecklege; eine Ortsumgehung auf einer Landesstrasse. Schon seit 
einigen Tagen hatte sich Grosses angekuendigt: Strassennahe Baeume waren 
gefaellt, eine Flaeche neben der Strasse plattgewalzt worden, Bagger und 
Planierraupen standen bereit. Nun war die Strasse an dieser Stelle 
gesperrt (ich glaube, sie bauen einen Kreisverkehr), und die 
ausgeschilderte Umleitung fuehrte durch das Dorf, das ueblicherweise 
"umgangen" wird.

Die Folgen dieser Baustelle sind in OpenStreetMap-Notation weitreichend; 
die Umleitungsstrecke durch das Dorf hindurch ist jetzt vollstaendig mit 
Parkverboten gesaeumt und hat ihren "LKW nur fuer Anlieger"-Status 
verloren. Ein Dorf auf der gegenueberliegenden Seite der Strasse ist 
normalerweise komplett "Anlieger frei", auch diese Regel ist fuer die 
Zeit der Baustelle ausser Kraft gesetzt.

Waere hier alles vollstaendig getaggt (inkl. Parkverboten und Anlieger 
frei), dann muesste ich sicherlich so 30, 40 Objekte anfassen, um dieser 
Baustelle gerecht zu werden - und alles wieder retour, wenn die Arbeiten 
abgeschlossen sind.

Solche voruebergehenden Aenderungen sammeln sich natuerlich alle auch 
unserer Objekt-History an, die damit immer weiter aufgeblaeht wird.

Die Relevanz dieser Aenderungen haengt von der Anwendung ab. Eine 
Routing-Anwendung, wenn sie benutzt wird, um live zu navigieren, sollte 
Zugriff auf die veraenderten Daten haben. Eine Routing-Anwendung, die 
z.B. von einer Baeckerei benutzt wird, um den idealen Standort zu finden 
(wo haben die meisten Kunden zu mir die kuerzesten Wege), sollte solche 
voruebergehenden Aenderungen eher nicht beherzigen. Eine Karte, die ich 
den Teilnehmern eines Radrennens am Wochenende an die Hand gebe, braucht 
diese Daten; eine Karte, die jemand nutzen will, um sich zu ueberlegen, 
wo er ein Haeuschen kauft ("ah, das hier ist alles Anlieger-frei-Gebiet, 
da laesst es sich verkehrsarm wohnen") sollte eher den "status quo ante" 
zeigen.

In der Luftfahrt gibt es amtliche Karten, die die verschiedenen 
Luftraeume und Sperrgebiete zeigen. Zusaetzlich gibt es zeitlich 
befristete Publikationen ("NOTAM" - "Notice to Airmen"), die auf 
voruebergehende Sperrungen oder Aenderungen seit der letzten 
Kartenpublikation aufmerksam machen. Vor einem Flug sollte der Pilot 
sich immer vergewissern, ob NOTAMs seine Strecke betreffen.

Mein Gedanke ist nun, dass wir etwas aehnliches fuer OpenStreetMap 
einfuehren sollten - ich nenne es mal OSM-T, "OSM transient", fuer 
voruebergehende Aenderungen. Ich wuerde also in unserer normalen 
Datenbank stets nur den "Normalzustand" speichern, und in OSM-T 
eventuelle aktuelle oder kuenftige Ausnahmezustaende. OSM-T wuerde sich 
stets auf Objekt-IDs aus der normalen OSM-Datenbank beziehen. OSM-T 
muesste eine Art Durchreiche-Service haben: Wenn man statt irgendwas 
direkt von OSM abzufragen stattdessen bei OSM-T anfragt, dann holt OSM-T 
die Daten von OSM, reichert sie um aktuell gueltige temporaere 
Aenderungen an, und gibt das weiter. OSM-T koennte spezielle "diffs" 
publizieren, so dass man jederzeit auf eine existierende OSM-Datenbank 
einen aktuellen OSM-T-Diff applizieren kann, wenn einen nicht der 
"Normalzustand", sonder der aktuelle "Ausnahmezustand" interessiert. 
OSM-T muesste natuerlich begrenzt in die Zukunft reichen - man muss dort 
auch eine Aenderung eingeben koennen, die erst in einingen Wochen aktiv 
wird, und auf Anfrage muss ein Benutzer auch den voraussichtlichen 
Zustand in einer Woche abfragen koennen oder so.

Das ist alles noch nicht ausgegoren; insbesondere ist es eine 
Herausforderung, die referentielle Integritaet zu wahren (was ist, wenn 
jemand in OSM einen Way loescht und neu macht, zu dem in OSM-T aber eine 
spezielle Ausnahmeregel steht). Editoren muessten ein OSM-T-Modul haben, 
mit dem man die OSM-T bekannten Ausnahmen in einem Spezial-Layer sieht, 
und die Editoren muessten einen Modus haben, dass man sagen kann: 
"Alles, was ich ab jetzt aendere, soll eine temporaere Ausnahme bilden, 
die ab naechstem Montag gilt und zu OSM-T hochgeladen wird" oder so.

Es gibt ja immer wieder verschiedene "lifecycle"-Konzepte fuer OSM, und 
fuer einiges haben die auch ihre Berechtigung, aber bei Dingen, die klar 
nur voruebergehend sind, sehe ich OSM selbst eigentlich ueberlastet.

Haben sich das andere Leute auch schon ueberlegt, und zu welchen 
Schluessen seid ihr gekommen?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"