Landkreise + Idee einer "Stable Map"

Misterboo, ich denke das ist ein natürlicher Reflex, der auftritt wenn jemand (ich übertreibe) “der keine Relationen editiert uns vorschlägt wie wir uns zu organisieren haben”. Versteh es bitte nicht falsch, aber an der Organisation des projektes wirst du #on oben oder durch Abstimmung nichts ändern.

Was du ja möchtest (und jeder hier gut findet) , ist eine bessere möglichkeit QS hier zu leisten und dadurch mehr leute fü) das Thema zu begeistern. mikel Maron ist gerade auf TALK dabei (siehe WN) Erweiterungen der user Seite einzubauen und ein Dashboard einzubauen. Dort würde sich ein fehlerreport sehr gut machen!

bei uns läuft es nur durch selber machen, leider ist das lokale Aufsetzen eines Rails Ports nicht so leicht, weshalb es viele abschreckt an der Hauptseite zu arbeiten

Ich kann das aus meiner Erfahrung nicht bestätigen, es kommen hier deutlich weniger neue Fehler hinzu, als entstehen.

Je vollständiger die Datenbank ist, umso weniger Änderungen gibt es und umso stabiler wird diese werden.

Ich vermute, dass die Nutzung der Daten stark zunehmen wird und es dadurch mehr Menschen gibt, denen vorhanden Fehler auffallen und welche ein Interesse daran haben diese zu beheben.

Gruß,
Mondschein

Sorry, ich möchte deine Diskussion nicht abwürgen. Aber ich sehe nicht das du auf die Argumente eingehst. Der Weg für dich ist, dass Fehler im Changeset abgelehnt werden müssen. Das Betrifft nur wenige Keys.
Oliwan ist bereit mit zu arbeiten. Macht für die ganze Welt 2 Personen. Macht ihr einen Dienstplan? damit die Änderungen wie heute schnell verfügbar sind? Wenn ich heute schon Nutzer sehe, die verzweifeln weil Mapnik nicht nach 10 Minuten ihre Änderungen zeigt, dann werdet ihr wie auch immer keine Chance haben diese Ansprüche zu erfüllen. Damit scheitert das Projekt immer!
Also dein Beispiel zeigt 4 Relationen die defekt sind. Hey das ist wenn man will ich 20 Minuten erledigt. Das wollte ich damit sagen. Und wenn wieder neue Fehler hinzukommen, dann kann man sich ja mal anschauen ob die immer vom selben stammen. Diesen Nutzer anschreiben ist wesentlich besser, als alle Nutzer perse als Fehlerquelle zu betrachten. Und das bei 20 Changesets mit mehren 100 Objekten auch dem Kontrollteam ein Fehler unterläuft ist denke ich nicht unmöglich oder?
Also ich denke der einzige Weg zu besseren Daten führt über die QS Tools welche die Fehler in den Daten aufspüren und anzeigen. Dann wird es immer wieder Menschen geben, die diese Fehler beheben. automatisiert kann man sowas nicht machen. Denn sonst hätte schon längst jemand einen Bot programmiert.
Welche Möglichkeit also siehst du?
Von !i! angesprochen ist eine automatische Prüfung ob eine geschlossene Grenze geschlossen ist. Das könnte sicher ohne große Probleme bewerkstelltig werden. Allerdings heißt das nicht das die Grenze dann richtig ist.

Vorab: Ich hab den Thread jetzt nur überflogen, bitte verzeiht mir das oder ignoriert meinen Beitrag.

Ich denke, grundsätzlich wäre es schon möglich, ‘stabile’ Datensätze anzubieten. In gewisser Weise passiert das ja schon - die Planetfiles sind ja stabile (im Sinne von nicht mehr veränderlich, nicht im Sinne von fehlerbereinigt) Auszüge aus der Datenbank. Was fehlt, ist das, was bei Software nach solch einer Fixierung eben passiert: Es wird nicht nur an dem veränderlichen Zustand für die Zukunft gearbeitet, sondern parallel dazu werden in dem schon festgesetzten Auszug Fehler korrigiert. Das wäre auch bei OSM durchaus machbar: So, wie ab und zu Full-History-Planets veröffentlicht werden, könnte man in regelmäßigen Zeitabständen Planetfiles für ‘stable’ erklären, die dann in einer separaten Datenbank landen. In der würde sich dann ein Team darum kümmern, dass Fehler beseitigt werden und keine neuen dazukommen, z.B. indem Changesets für diese Datenbank individuell geprüft werden. Natürlich müsste auch klar sein, dass Changesets dort nur der Fehlerbehebung dienen sollen. Das Ganze würde dann unabhängig von der eigentlichen Datenbank laufen und irgendwann, wenn der soundsovielte stable-Nachfolger draußen ist, eben aufgegeben werden.
Nur: So etwas wird es denke ich in absehbarer Zeit nicht ‘offiziell’ von der OSMF auf den OSM Servern geben. Zum einen, weil der Betreuungsaufwand wohl enorm wäre, zum anderen, weil man eben ein offizielles Team dafür einsetzen müsste, was nicht jeder gut fände und zu Konflikten führen dürfte.
Andererseits ist OSM sowieso eine do-ocracy, sprich, wenn sich einer findet, der das Ganze, so wie oben beschrieben (oder natürlich auch gerne anders) aufzieht, könnte man es demnächst schon haben. Natürlich erfordert es einiges an Ressourcen, technische wie personelle, aber ich denke, ein engagiertes Team könnte sowas durchaus auf die Beine stellen.
Jedenfalls kann man so ein stable map System meiner Meinung nach am Besten möglichst getrennt von der Hauptdatenbank anfangen und damit muss nicht unbedingt die OSMF tätig werden, um es zu ermöglichen.

Meinst du diesen Vorschlag ernst? Ich habe ein Problem damit, wenn Mapper dann damit beschäftigt sind Fehler zu beseitigen und die aktuelle Datenbank davon nicht mehr probiert.
Außerdem muss man sich dann darüber einigen was Fehlerbereinigung ist und was neu ist. Schon wenn man Dinge für das Routing verbessert wird diese Abgrenzung schwierig. Wie wird das dann mit Straßen die nicht mehr befahrbar sind etc. Ist das noch Fehlerbereinigung?

Ob ich das ernst meine? Ja, natürlich. Ich meine, ich will nicht sagen, dass sich ein Haufen Leute damit beschäftigen sollten, statt zum aktuellen Datenbestand beizutragen. Aber wir können keinem vorschreiben, was er zu tun hat - und wenn jemand lieber das tun würde, fände ich das in Ordnung. Natürlich geht dadurch Arbeitskraft für die Hauptdatenbank verloren. Dafür hätte man aber auch große Vorteile durch die Bereitstellung stabilisierter Versionen. Ob das nun die Nachteile aufwiegt oder nicht, muss jeder für sich wissen, ich habe nur gesagt, wie ich mir technisch vorstellen könnte, das so etwas funktioniert. Und die Idee, von OpenSource Software zu kopieren, kam ja nicht von mir - und da (und auch bei proprietärer Software) ist es durchaus üblich, dass sich eben Leute um ältere, aber stabilere Datenbestände kümmern, auch wenn sie dadurch nicht zur Weiterentwicklung beitragen. Siehe z.B. die Linux Kernel Versionen, die weiterbetreut werden.
Was Fehlerbereinigung ist, könnte dann natürlich derjenige entscheiden, der das Projekt verwaltet. Deshalb sage ich ja, dass es das wohl kaum offiziell geben wird. Aber wenn ich mich morgen hinsetzen würde und mit so etwas anfangen und meinetwegen Routingfehler beseitigen würde, dann wäre das, was rauskommt, eben eine für’s Routing stabilisierte Version. Wenn jemand anderes andere Ziele hat, kann er die ja ebenfalls verfolgen. Wie gesagt, alles eine Sache derjenigen, die sich die Arbeit machen, und nichts, was man von außen versuchen sollte, zu steuern.

Das Team bräuchte dann aber lokales Wissen und müsste dementsprechend groß sein, das erscheint mir kaum möglich.

Evtl. könnte man täglich automatische Routing-Analysen (zumindest bei großen Straßen) durchführen lassen und dann entsprechende Meldungen/Änderungen manuell überprüfen (lassen).

Software-Projekte sind hier kaum vergleichbar.

Gruß,
Mondschein

Ich denke man müsste das laaaannnnngggggssssaaaammmm machen.
also zuerst zB: wichtige Grenz und küstenrelationen dann Autobahnen usw.

Ich würde das auf Basis einer automatischen überwachung ob gewisse relationen oder Routings sich verändert haben.
Dies sollte auf einer öffentlichen automatisierten benutzerfreundlichen Homepage zu sehen sein.

Also wenn zum Beispiel einer eine die deutsche Grenze hochlädt und diese ist nachher nicht mehr am Stück könnte doch derjenige (und eingetragene “abbonennten” der Grenzrelation) eine Nachricht erhalten dass diese nun “kaputt” ist.
So hat schon mal der user selbst die möglichkeit seinen Fehler zu fixen.

Und dass sollte langsam ausgebaut werden um die wichtigsten dinge fürs routing zu überwachen.

Damit kann man dann doch öfters eine “teilweise stable map” machen wo man “garantiert” dass gewisse Ziele erreicht wurden.

was haltet ihr davon?
leider bin ich kein programmierer…

Das ist ungefair das was OSM Inspector und Keepright schon machen. Nur eben ohne darüber zu benachrichtigen. Und auch nicht auf 5 Minuten aktuell.

@Mondschein: Wie gesagt, dass kommt auf die Ziele an. Wenn man nur die wichtigsten, offensichtlichsten Fehler ausbessern will und eventuell in Kauf nimmt, dass nach ‘Korrektur’ eine Stelle vielleicht nicht absolut akkurat, dafür aber routing(-/render-/sonstwas-)fähig ist, muss kein besonderes lokales Wissen vorhanden sein. Wenn man die Plattform so öffnen würde, dass jeder (oder zumindest ein großer Personenkreis) Korrekturen vornehmen kann, die aber von einem Team eben individuell zumindest auf logische Korrektheit und offensichtliche Fehler geprüft werden, müsste dieses Team ebenfalls kein lokales Wissen haben - es würde einfach alles, was nach Verbesserung (im Hinblick auf das gesetzte Ziel) aussieht annehmen und den Rest verwerfen. Das der Maßstab ein anderer als bei Softwareprojekten ist, sollte klar sein, nichts desto trotz halte ich es durchaus für durchführbar, wenn sich da ein paar Leute dahinterklemmen würden (und das Interesse an solchen Datenbankauszügen da ist - aber das wurde ja schon mehrfach bekundet). Im Endeffekt wäre es eben ein Drittanbieterservice. So wie die geofabrik Grenzpolygone bereitstellt oder Leute Karten für bestimmte Zwecke und oder Endgeräte konstruieren.

Und was ich noch an viw vergessen hatte: Es würde ja, geeignete Infrastruktur vorausgesetzt, nichts dagegen sprechen, Korrekturen an der Extradatenbank zur Hauptdatenbank zurückfließen zu lassen (und zwischen den Extradatenbanken für verschiedene Versionsstände). Wenn das relativ schnell läuft, sollte es meist ohne Konflikte laufen, wenn nicht, kann man die immernoch händisch beheben oder in diesem Fall eben die Korrektur verfallen lassen. Nur ein Fluss Hauptdatenbank → Extradatenbank dürfte nicht stattfinden, zumindest nicht ohne jedes Changeset zu kontrollieren und das dürfte wohl viel zu aufwendig sein, bei der Masse an Änderungen an der Hauptdatenbank.

Ich habe keine Ahnung welche Vorstellung ihr von der Fehlerkorrektur habt. Entweder gibt es in dem Datenbank auszug nur wenige Fehler, dann sind die Zeitnah schnell behoben. Wenn es aber viele Fehler sind, und damit die Bearbeitungszeit länger ist, besteht die Gefahr, das die Objekte in den anderen Datenständen gar nicht mehr in der Art existieren. Da sind aus Straßen eben Flächen geworden oder aus einer Straße eben zwei als Richtungsfahrbahnen. Wenn wir uns anschauen zu welchen Konflikten es schon kam in der normalen Datenbank als nur wenige hochauflösende Luftbilder zur Verfügung standen, dann ist das denke ich abwegig zu sagen, dass dies hier nicht auftreten wird.
Daher bin ich immer noch der Meinung, dass die Fehler in der eigentlichen Datenbank beseitigt werden müssen, sonst macht man sich die Arbeit zweimal. Und alle die mehr von den Daten wollen, sollen geeignete Methoden finden/anbieten damit es sich ändert.
Die Geofabrik macht das ja auch nicht zum Spaß. Sie verdienen damit Geld. Und den anderen Playern im Boot wird es ähnlich gehen. So trägt jeder seinen Teil zum Ökosystem bei.

Auch ich gestehe -wie errt- nicht alles im Detail gelesen zu haben. Aber ich kümmere mich regelmäßig um das Thema DQ [wenn auch mehr im Bereich Tagschreibweise (besonders im Umfeld Adresse)] und auch beruflich habe mit diesem Thema Berüherungspunkte.

Eine der wichtigsten Grundaufgaben im Bereich DQ ist eine Meßgröße festzulegen, um den DQ-Zustand der Daten festzuhalten (einfache OSM-Beispiel: Anzahl der oneway Tags mit unbekannten Werteausprägungen siehe http://www.familieverweyen.de/txt_0054.php)).

Dann muss eine (messbare)Definition festgelegt werden, was einen Datensatz mit gut Qualität (bzw. akzeptabler Qualität) und nicht ausreichender Qualität auszeichnet. Also z.B.: wenn sich bei einer Verwaltungsgrenze (nach Auflösung aller potentiellen Unter-Relationen) eine Menge von in sich geschlossene Wegen bildet, die sich nicht überlappen. (Akzeptabel wäre, wenn die Wege nach einer Sortierung (und ggf. Richtungsänderung) eine solche Menge bilden würden.) [Bewußt vereinfacht dargestellt!]

Danach muss man sich eine Menge der zu messenden Objekte festlegen (z.B. admin_level < x). In den Changeset-Dateien kann man sich dann alle Objekte mit diesem Schlüssel herausfischen und die Kontrolleroutine dazu laufen lassen. Wenn man keine große DB aufbauen will, sollte man sich die notwendigen Daten aktuell aus der Overpass-API organisieren.

Man sollte beachten, dass man natürlich nur entdecken kann, was man auch messen kann bzw. zum DQ-Merkmal bestimmt hat. Wenn sich im obrigen Beispiel zwei Gemeindegrenzen wohlsortiert und überschneidungsfrei abbilden lassen, können sich immer noch die beiden Gemeindegebiete überlappen und dies wäre mit den definierten Messungen nicht erkennbar (Merke: wichtig ist also eine vollständige Definition von guter Qualität).

Wenn erkannt werden soll, dass Daten mit admin_level=x gelöscht werden, wäre dies wahrscheinlich nur durch regelmäßige, resourcen intensive Abfrage aller Verwaltunsggrenzen möglich (Fläche aller Verwaltunsgrenzen mit admin_level=n+1 ist identisch mit der Fläche mit admin_level=n, Anzahl der Objekte reicht leider nicht ganz, denn hier kann es bei Verwaltungsreformen zu zuvielen Fehlalarme kommen). Allein aus diesem Grund wäre es sinnvoll eine lokale Liste (Datentabelle) aller bekannter Objekte mit Ihren Qualitätsmerkmal zu halten, dazu müsste man aber auch alle gelöschten Objekte (zumindestens Relationen und Wege, Knoten entfallen wohl bei diesem Fall), gegen die Liste der bekannten Objekte prüfen.

Mein persönliche Meinung ist, dass man sich nicht unbedingt vor April mit einem sehr schwierigen Variante dieses DQ-Thema beschäftigen sollte.

MfG Georg V. (OSM=user_5359)

Fast hätte ich das wichtigste Werkzeug vergessen:
http://matt.dev.openstreetmap.org/owl_viewer/

Gruß,
Mondschein

Eigentlich eine gute Idee wäre die Einführung eines “geschützt”-Bits. Die Datenbank (und über eine API der Editor) fragt beim Bearbeiten von Objekten, bei denen das Bit gesetzt ist, nach, ob die Änderung wirklich gewollt ist. Von mir aus mit erneuter Passworteingabe, die nicht gespeichert werden kann. Nur wenn der Editor diese API-Änderung implementiert hat, kann der Nutzer die Änderung bestätigen. Dieses Bit kann allerdings jeder setzen oder löschen. Eventuell machts Sinn, dieses Bit nutzerseitig auf einen Tag zu mappen (z.B. locked=yes).

Damit ließen sich Autobahnen, Grenzen, Relationen und weitere kritische Objekte vor versehentlichem Verändern schützen. Wenn man weiter gehen möchte, knüpft man daran bestimmte Nutzergruppen, ähnlich wie in der Wikipedia beim Sichten. Wichtig ist jedoch, dass nicht alle Objekte geschützt werden, sondern nur die besonders kritischen.

Das war mein Brainstorming. Ich hoffe, dass das Thema Qualitätssicherung an der SotM ein Thema sein wird, am besten mit Beschlüssen.

Stimmt…an Blockwarten mangelt es in OSM noch…

Glaubst du ernsthaft, dass das locked=yes sich auf gewisse Daten begrenzen lässt? Die Folge wird sein, dass Mapper auf die Idee kommen, alle ihre Daten zu schützen, weil die sind ja so richtig. Ist ja an sich auch nicht verwerflich, weil genau dafür ist ja das Tagg gedacht. Nun kommt aber so ein naiver Mapper daher und möchte durch den geschützten Ort nur eine Radweg-Relation legen. Er splittet die entsprechenden Wege auf, verlegt die Relation und beim Hochladen kommt dann das böse erwachen. dutzende Male muss er das Passwort eingeben und bestätigen, dass er wirklich den Weg teilen wollte.
Was glaubst du wie lange der Mapper das mitmacht?

Es gibt bei OSM keine Instanz (und wird es wird nie eine allgemein etablierte Instanz geben), die entscheidet, wann ein Objekt so richtig und vollständig ist, dass er nicht mehr einfach verändert werden sollte.

Halte ich für eine problematische Idee.
Ich habe gerade eben eine Bundesstraße teilen müssen, weil ich sie an die reale Situation der Rad-/Fußwege an einer Einmündung anpassen wollte. Wenn die Bundesstraßen-Relation oder gar die Straße als solche gesperrt gewesen wäre, hätte ich ziemlich alt ausgesehen. Beliebige andere Beispiele wo das enorm stören würde, lassen sich sicher leicht finden.

Im Grunde widerspricht es der OSM Idee, dass jeder Änderungen/Verbesserungen an jedem beliebigen Objekt durchführen kann und darf. So eine generelle Einstellung sollte man nicht leichtfertig über Bord werfen.

Die Idee Nutzergruppen mit Sonderrechten auszustatten ist auch etwas, was man nicht mal so nebenbei einführen sollte. Das will gut überlegt sein, ob man so etwas bei OSM überhaupt haben will.

Edbert (EvanE)

Stimme ich zu. Laut dem Buch “Alles über Wikipedia” werden die Moderatoren dort sehr sehr kritisch gesehen, wir sollten probieren diese Klippe bei OSM zu umschiffen. Ein Ansatz dafür wäre für ebend diese zerbrechliche Sachen einen stable Epxort einzuführen, bei dem nur die letzte funktionierende Objektinstanz ausgeliefert wird.

Danke für die schnellen Antworten! Ich sehe ein, dass das keine allzu gute Idee war. Das einzige was mir aktuell als Möglichkeit einfällt, sind Editoren, die mögliche Fehler erkennen und nachfragen. Im Prinzip läuft das ja schon so mit JOSM.

Vermutlich haben wir weniger mit Trollen zu tun, sondern mit Neulingen, die unabsichtlich Sachen beschädigen. Am kritischsten sind in meinen Augen Relationen und Fernstraßen.

Werden unsere Daten nun z.B. für Navis verwendet, lädt sich der Hersteller das Planet-File runter, wurschtelt bisschen drauf rum und haut es aufs Gerät. Dort wird es ohne Update vielleicht zwei Jahre drauf sein. Wenn genau in dem Moment des Downloads die Autobahn an irgendeiner Stelle in Deutschland kaputt ist (und wenns nur 10 Minuten waren), wird der Nutzer immer falsch navigiert werden.

Das wäre, mit Verlaub, ein ziemlich schwachsinniges Vorgehen auf Herstellerseite.
Jede vernünftige Firma verfügt über eine “Wareneingangskontrolle” um sich vor Mängeln der gelieferten Rohprodukte zu schützen.
Dies sollte auch für Softwarehersteller sinnvoll sein.
Z.B. könnte man als Hersteller von Navi-Software einige Hundert Testpunkte für Testrouten erstellen und damit automatisch die Datenqualität an den relevanten Ecken überprüfen.
Ansonsten gilt: “garbage in - garbage out”. http://de.wikipedia.org/wiki/GIGO

Gruss
Walter

Naja es würde ja schon reichen, wenn die Hersteller eine zuverlässige Feedback Funktion hätten und sich auch von unserer Community was sagen ließen