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 [email protected] ## N49°00'09" E008°23'33"
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
