[Talk-de] Koennen wir die TMC-Daten rauswerfen?

[André Reichelt]

Am Samstag, den 05.02.2011, 19:32 +0100 schrieb Frederik Ramm:
> Das ist ja dann der absolute UI-GAU. "Lieber User, mit diesem Objekt 
> hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade 
> machen willst, kann Folgen haben, die Du nicht verstehst und die wir 
> hier leider auch nicht erklaeren kann..." - das ist *genau* der Kern des 
> Problems.

Das wird sich aber auch nicht durch eine ID in eine externe Datenbank
lösen lassen, da auch hier der User zunächst überprüfen muss, was das
Tag bedeutet und wie er hier vorgehen muss. Also bringt uns auch die
Geforderte ID in eine externe Datenbank keinen Schritt weiter.

Außerdem haben wir bereits festgestellt, dass man von einer anderen
Datenbank nicht in die OSM-Datenbank linken kann, da hier die Gefahr
groß ist, dass irgendwer ein paar Nodes/Wege löscht und dadurch die
externe Datenbank ständig korrigiert werden müsste.

Wir stehen hier meiner Meinung nach vor einem schwerwiegenden Problem,
für das wir gegenwärtig keine Lösung parat haben. Nun einfach ohne
Rücksicht auf Verluste zu fordern all diese Tags wieder zu löschen wäre
falsch und destruktiv.

> Es mag sein, dass es manchmal einfach nicht anders geht, und dann kann 
> man mal einen Kompromiss machen, aber es sollte wenigstens klar sein, 
> *dass* solche Tags schaedlich sind und dass man, wenn es irgend geht, an 
> ihrer Vermeidung arbeiten sollte statt an ihrer Vermehrung.

Dass solche Tags »schädlich« sind konnte bisher noch niemand mit Fakten
belegen. Die einzige Aussage die hier von Dir und von Anderen glaubhaft
vermittelt werden konnte ist, dass die gegenwärtige Lösung suboptimal
ist.

Wir stehen nun also an dem Punkt, an dem wir dazu angehalten sind eine
*bessere* Lösung zu finden. Dieses Ziel werden wir nicht erreichen,
indem wir hier in Wikipedia-Manier irgendwelchen relevanzkriterien-
ähnlichen Mist veranstalten.

Ich möchte das Problem noch einmal allgemein gefasst darstellen:
Wir haben eine externe Datenquelle, die mit der OSM-Datenbank verbunden
werden soll. Eine direkte Verbindung mit der OSM-ID des Objektes nicht
nicht möglich, da es in der OSM-Datenbank keinen »Fertig«-Zustand gibt,
der ein Löschen oder Verändern des Objektes dauerhaft ausschließt. Daher
muss ein Weg gefunden werden unabhängig von zukünftigen Änderungen an
der OSM-Datenbasis zuverlässig eine Verknüpfung von OSM-Daten mit einer
externen Datenquelle zu gewährleisten.

Ich behaupte, dass wir hier von einem komplexeren Problem sprechen, dass
sich durch blinden Aktionismus nicht lösen lässt. Bevor jedoch keine
zuverlässige und stabile, weniger »schädliche« Lösung gefunden ist kommt
eine Löschung der TMC-Daten nicht in Frage, da dadurch die
Datennutzbarkeit in erheblichem Umfang eingeschränkt wird.

Gruß
André



*Anhang:* Meine Idee für einen Lösungsansatz

Ein Lösungsansatz könnte es sein, nicht nur auf das Objekt in der OSM-DB
selbst zu verweisen sondern zusätzlich auf den Revisionsstand. Auch hier
könnte es allerdings zu konflikten mit zukünftigen Änderungen kommen.
Von unserer Seite aus müsste bei diesem Ansatz also ein System
geschaffen werden dass zwar die Datenbasis *möglichst* aktuell zur
Verfügung stellt. Wird jedoch in der Dump-Abfrage ein Objekt mit
Revision abgefragt muss die Blackbox in der Lage sein alle involvierten
zukünftigen Änderungssätze zu ermitteln, dort eventuelle Konflikte
feststellen und die betroffenen Daten vor der Ausgabe auf einen
konsistenten Revisionsstand zurücksetzen.

Als Zwischen-/Notlösung könnte man sich auch vorstellen, dass einfach
nur eine Liste von Objekten und deren Revisionsstand an die Blackbox
übergeben wird. Diese gibt dann für jedes Objekt zurück, ob es
mittlerweile einen neuen Revisionsstand hat. Diese Lösung hat allerdings
den Nachteil, dass ich als Betreiber der externen Datenquelle, die in
OSM linkt zunächst meinen Datensatz überprüfen muss und im Konfliktfall
meine Verknüpfungen zu korrigieren habe.