Vorschlag: Qualitätskontrolle-Tag für Tags

MADetter · 2008-08-06T13:32:15.000Z

Hallo, da ich noch sehr neu bin und mich erst einlese, weiß ich nicht ob sich schon jemand Gedanken gemacht hat darüber. Ich habe aber noch nichts dazu gefunden. Angenommen mehrere Logger/Tagger treiben sich in derselben Gegend rum und überprüfen sich gegenseitig auf die Qualität ihrer Tracks und Tags. Für Tags könnten diese (mehrfache) Überprüfung und Bestättigung von key-Value-Kombinationen eine interessante Zusatzinformation sein, z.b. um unvorsichtige User zu warnen gut bestättigte und aktuelle Informationen zu ändern. Außerdem kann man ein Stück weit die Qualität der Informationen dokumentieren. Ich schlage darum folgende Tags vor (natürlich bestehe ich nicht auf die konkrete Bennung :)): REVIEW: = / //Wann war der letzte Review des keys und von wem REVIEW_CONUT: = //Wie oft wurde die aktuelle = -Kombination schon beobachtet Die Tags würden bespielhaft folgendermaßen angewendet: Der User MADetter ist in einem getaggten Bereich unterwegs und merkt sich ein paar Straßennamen. Zurück am Rechner schaut er in OSM nach ob sie stimmen. Stimmen sie trägt er folgendes ein: “REVIEW:name = MADetter/2008-8-6” (oder auch ein anderes Datumsformat) und wenn er der erste war: “REVIEW_count:name = 1” ansonsten erhöht er der Wert von REVIEW_count:name um 1 Findet er einen falschen Namen, ändert er den Namen der Straße und löscht die beiden oben genannten Tags. Zusätzlich würde ich für Tagger/Logger, die sich für ein bestimmtes Gebiet zuständig fühlen folgenden Tag vorschlagen: PLEASE_NOTIFY = ;… Jedesmal wenn etwas geändert wird, wünschen die sich dort eintragenden User darüber informiert zu werden, um die Sachlage überprüfen zu können Für mein Dorf (was ich dieses Jahr in OSM bringen will würde ich mir sowas wünschen. MfG Mark

Tordanik · 2008-08-06T13:50:51.000Z

Zusätzlich würde ich für Tagger/Logger, die sich für ein bestimmtes Gebiet zuständig fühlen folgenden Tag vorschlagen: PLEASE_NOTIFY = ;… Jedesmal wenn etwas geändert wird, wünschen die sich dort eintragenden User darüber informiert zu werden, um die Sachlage überprüfen zu können Für mein Dorf (was ich dieses Jahr in OSM bringen will würde ich mir sowas wünschen.

Das würde ich definitiv nicht in die Datenbank schreiben, die Sachen müssen sonst wieder beim Bearbeiten ausgeblendet werden, bei Weiternutzung außerhalb von OSM wäre es nutzloser Ballast, es müsste eine Zugriffskontrolle geben (sonst trägt einfach ein Vandale die zu benachrichtigenden User aus …) etc. Ist außerdem schon mit externen Tools möglich (leider proprietär, aber brauchbar): Auf http://www.itoworld.com/static/osmmapper kann man sich RSS-Feeds zu Bearbeitungen an Ways in einem frei gewählten Gebiet abonnieren, auch nachzulesen hier: http://forum.openstreetmap.org/viewtopic.php?id=1118.

MADetter · 2008-08-06T13:56:58.000Z

Danke für den Hinweis Tordanik. Allerdings kann sich niemand in OSM gegen Vandalismus schützen - man vertraut eben ein Stück weit den anderen Usern. Hmmm… was ist deine Meinung zu den REVIEW-Tags? MfG Mark

MADetter · 2008-08-06T19:45:27.000Z

Mir ist eben noch eine zusätzliche Idee/Alternative gekommen: Da bei den Reviewed-Tags nun verschiedene Leute dieselbe Information einpflegen (indem sie sie bestättigen) könnte man anstatt des Counts auch den source-Tag adaptieren und erweiteren. Anstatt des Review_Count-Tags könnte man für jeden Tag eine Source benutzen der Form: source: = ();();… (natürlich sollten die Editoren das ganze durch eine Art Wortvervollständigung passend unterstützen) Angenommen 3 Leute haben einen Straßennamen durch persönliche Untersuchung, 2 durch Abgleich mit einem lizenzfreien Stadtplan und 1 durch Abfrage seiner höchst eigenen Adress-Kundendatenbank überprüft. Dazu kommt noch derjenige der den Wert als erster gesetzt hat und zwar indem er auch die Straße persönlich abgelaufen ist. Es ergibt sich damit: source:name = survey(4);city_map(2);MyCompanyDataBase(1) Wird der Name aufgrund von politischen Umstürzen geändert würde man es entsprechend ändern: source:name = decision(1) Weiterhin brauchen wir immernoch den REVIEW:name-Tag um nachzuvollziehen wie aktuell und von wem die letzte Änderung war: REVIEW:name = LocalWarLord666/2102-2-29 MfG Mark

Markus_B · 2008-08-06T19:57:59.000Z

Hallo Mark, ich denke grad ebenfalls an diesem Thema rum… Bei Seezeichen ist die Validität der Daten manchmal lebenswichtig. Wir denken an: PosLat: die genaue Position (amtliche Daten oder GPS), falls mal jemand versehentlich was verschiebt PosLon: PosDat: Datum der Überprüfung PosRef: Name des Prüfers Aber eigentlich bräuchte man eine Änderungshistorie… Gruss, Markus

MADetter · 2008-08-06T20:10:58.000Z

Hallo Markus, für sicherheitsrelevanten oder anderen Daten, bei der Invalidität nicht nur ein Ärgernis ist, stimme ich dir voll zu, außerdem bräuchte man dafür dann Leute, die dafür gerade stehen, dass die Werte stimmen. Eine freier Zugriff auf diese Tags dürfte es nicht geben - außerdem bräuchte man gleich noch ein Sicherheitskonzept gegen Verfälschung auf Ebene der IT - Samt Zugriffs- und Zugangskontrollsystem und Haftungserklärungen. Außerdem bräuchte man noch Zertifikate für die Darstellungssoftware ect., ect., ect. Auf kein Datum hier in OSM kann man sich WIRKLICH verlassen - das darf man NIE aus den Augen verlieren. Weder bei krassen Bergtouren, noch Segeln noch Survivaltouren durch die Rockies kann man auf zertifizierte Daten verzichten. Bei weniger kritischen Daten wäre jedoch eine Aussage, wie aktuell und wie oft bestättigt die Daten sind, schon interessant. Deine Tags würden quasi ein Spezialfall meiner Darstellung sein. Sollen Prüfer und Datum wie bei mir jeweils auch die des letzten Prüfers sein? MfG Mark

Markus_B · 2008-08-06T20:44:39.000Z

Hallo Mark,

MADetter:

Sicherheitskonzept

Ja, da werden wir letztlich nicht drum rum kommen. Es ist für sensible Daten notwendig - aber im OpenSource-Umfeld nicht unproblematisch. Auch im Land-Bereich wird das Thema beim Routing relevant. Damit nicht einer mal schnell eine Autobahn sperren kann und die Autofahrer dann unsinnigerweise durch das nächste Dorf umgeleitet werden. Im See-Bereich sind wir noch weit davon entfernt, wirklich eine Seekarte erstellen zu können. Und dann wirk erst mal längere Zeit erfolgreich das Prinzip der “viiielen Augen”. Aber später braucht man mehr als nur: “letzte Bearbeitung von”. Dann braucht man Änderungshistorie, Änderungsverifizierung, Änderungsverzögerung/-sperre. Übrigens: im Seekartenbereich gibt es standardisierte Prüfverfahren, die frei verfügbar sind (Kontrolle der Darstellung der Daten). Die Daten selbst sind aber auch bei den Werken, die durch die Länder erstellt werden, von Land zu Land qualitativ unterschiedlich. Sogar in Deutschland gibt es wohl immer mal wieder ein Leuchtfeuer, das zwar im Verzeichnis aufgeführt ist, in Wirklichkeit aber schon längst nicht mehr existiert. Für OSM-Seekarten ist es wie gesagt noch zu früh, aber vielleicht können wir ja von Deinen Erfahrungen im Land-Bereich später mal profitieren. Gruss, Markus

MADetter · 2008-08-07T11:34:44.000Z

Meine Erfahrungen? Erfahrungen hab ich keine Eventuell wäre noch eine note:change: = “Nachricht warum ein Tag geändert wurde, und gleichzeitig die letzte Version des Tags enthält”… Die Frage ist immer, wieviel Speicherplatz wollen wir für eine vergleichsweise schlechte QS ausgeben… :-/ MfG Mark