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

Jan Tappenbeck osm at tappenbeck.net
Sa Aug 1 20:29:56 UTC 2009


Moin !

etwas ähnliches hatte ich schon einmal über zeitlich begrenzte Tags 
angeregt.

Es wird hinterlegt das eine Straße dann und wann fertig sein soll und 
entsprechend wird dann in der to-do / bug-seite entsprechend darauf 
hingewiesen.

diese gedanken sollten auf jeden fall mit eingebunden werden.

gruß Jan :-)

Frederik Ramm schrieb:
> 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
> 





Mehr Informationen über die Mailingliste Talk-de