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

[Frederik Ramm]

Hallo,

André Reichelt wrote:
> 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 haben vielleicht festgestellt, dass es nicht trivial ist; aber 
nicht, dass man es "nicht kann". Es braucht halt ein bisschen 
Gehirnschmalz, und mir es es lieber, die externen Datenbanken werden 
kompliziert und OSM bleibt einfach, als umgekehrt. Denn wir haben 
hunderte von externen Datenbanken und nur ein OSM ;)

Ideal waere, wenn es gelaenge, komplett von aussen nach OSM hinein zu 
linken. Das kommt ja immer wieder auf den Tisch, und die Alternativen 
sind immer die gleichen - entweder man macht es sich leicht und traegt 
die externe ID bei OSM ein, was aber auf Dauer ein Problem werden kann 
und anfaellig gegen Loeschungen usw. ist, oder man findet eine Art 
symbolischer Links - so dass in der externen Datenbank steht: "ein 
Objekt vom Typ Way oder Node mit den Tags amenity=restaurant und Name=La 
Cucina im Umkreis von 500m um diesen Punkt" oder so etwas. So eine 
Verknuepfung mit etwas "Spiel" ist immun gegen viele Probleme und 
verkompliziert OSM gar nicht - sie ist aber technisch anspruchsvoll, 
weil man eine XAPI-artige Link-Finde-Maschine braucht. In irgendeiner 
Weise wird es sowas aber geben muessen, und vielleicht koennte man das 
fuer TMC dann auch verwenden.

(Deine Idee mit dem Linken auf Revisionsstaende hat auch Charme, aber 
auch wieder ihre eigenen Probleme.)

> 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.

Ja, nun ist ja gut. Ich habe ja auch nicht gefordert, ohne Ruecksicht 
auf Verluste alle diese Tags wieder zu loeschen. Mir ist erstmal 
allgemein wichtig, grundaetzlich das Bewusstsein dafuer zu schaerfen, 
dass solche Tags weder gut noch unumgaenglich sind, sondern maximal eine 
Notloesung, weil wir "gegenwaertig" nichts besseres haben.

In bezug auf TMC wuensche ich mir, dass wir diese Daten mittelfristig 
weitgehend in ein OSM-externes System migrieren koennen, dass keinerlei 
regelmaessige automatische Veraenderungen von OSM fuer mehr 
TMC-Konformitaet stattfinden, und dass Benutzer, die sich nicht fuer TMC 
interessieren, nicht im Dunkeln tappen muessen. Wenn wir uns einig sind, 
dass es so, wie es jetzt ist, ganz bestimmt nicht "richtungsweisend" 
ist, dann ist das schonmal ein guter Anfang.

> 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.

Ein einziger User, der sich wegen TMC-Tags nicht traut, ein Objekt zu 
bearbeiten - und da gab es mindestens einen hier im Thread - reicht in 
meinen Augen schon zum "Schadensbeweis". Denk dran, dass sich hier in 
der Liste nur die "Top 1%" herumtreiben, und frage Dich, wie viele 
andere erschrocken ihre Finger von einer Verbesserung gelassen haben.

> Wir haben eine externe Datenquelle, die mit der OSM-Datenbank verbunden
> werden soll.

Jup. Und nicht: "Eine externe Datenbank, die in OSM abgebildet werden 
soll", was, wie mir scheint, derzeit der Fall ist.

> 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. 

Jup.

> 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.

"Zuverlaessig" und "gewaehrleisten" wird es nie geben. Was wir anstreben 
wuerden, waere allenfalls ein moeglichst geringes Risiko der 
unabsichtlichen Zerstoerung, sowie eine moeglichst einfache 
(automatisierte) Erkennung von solchen Problemen, so dass diese dann von 
Menschen repariert werden koennen.

> 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

Zu "zuverlaessig" und "stabil" s.o.

> 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.

Ehrlich gesagt scheint mir diese Datennutzbarkeit derzeit noch ein 
ziemliches Phantom zu sein. Das einzige, was ich gehoert habe, ist: 
"Mein Nuevi kann mir einen Punkt anzeigen, an dem die Stoerung ist". Das 
aber kann ich auch, indem ich 100% extern jedem TMC-Node ein 
Koordinatenpaar zuweise. Ich verstehe, dass das gewuenschte Ziel ist, 
dass Router automatisch Wegsegmente highlighten und ausblenden koennen, 
aber gibt es irgendeine Software, und sei es auch nur "proof of 
concept", die das macht? Oder reden hier alle nur von einer 
theoretischen, zukuenftigen, erhofften Nutzbarkeit?

Bye
Frederik

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