Neben der Neuerfassung, die irgendwann natürlich im Umfang stark nachlässt, gibt’s noch Fehlerkorrektur. Ein Mapper stellt z.B. fest, dass in der Adresse eines Hauses der Straßenname nicht stimmt. Ohne associatedStreet lässt sich das auf die denkbar simpelste Weise beheben: Haus anklicken und Eigenschaften ändern.
Das ist etwas, das sogar mit einfachen Editoren wenig oberhalb des Niveaus des Amenity Editor machbar wäre, und ich finde, dass wir die Einstiegshürde durchaus noch senken sollten. Leider geht der Trend derzeit anscheinend eher in die Richtung, dass erfahrene Mapper ein Konzept, sobald sie es verstanden haben, großzügig anwenden, was die Menge an Dingen, die ein Neuling verstehen muss, immer weiter in die Höhe treibt. Auch mobile Editoren finde ich für die nahe Zukunft ein interessantes Modell: Mit Luftbildern die Geometrie “vorzeichnen”, unterwegs dann auf dem Tablet oder Smartphone die Attribute der Objekte ändern und ergänzen. Das verlangt wiederum, dass es keine unnötig komplizierten Konstrukte gibt, die man ohne ein Werkzeug der Mächtigkeit von JOSM nicht handhaben kann.
Was mich gerade an associatedStreet auch stört, ist, dass sie selbst bei Dingen in die Quere kommt, die nichts mit Adressen zu tun haben. Bei einer Vollerfassung ist dann praktisch jede Straße in einer Stadt in einer Relation, was muss bei jeder Veränderung der Straßengeometrie berücksichtigt werden muss.
Die falsch geschriebenen Straßennamen findet man auch durch den Fehlschlag einer Zuordnung zu den Straßen in der Umgebung. Der OSM Inspector kann eine solche Zuordnung beispielsweise, also ist sie offenbar ohne associatedStreet automatisch durchführ- und überprüfbar.
PS: Nebenbei muss ich aber auch mal feststellen: Der Erfassungsgrad bei euch macht einen sehr guten Eindruck!
Also ich habe mit dieser Methode mehr als 8000 Adressen manuell gemapped und dabei für mich ein Verfahren für eine möglichst fehlerfreie Erfassung entwickelt.
Und ja der OSM Inspektor hat mir am Anfang auch geholfen. Aber wenn ich versehentlich einem Eckhaus die falsche Strasse zugewiesen habe, wurde das nicht entdeckt, da der Inspector nur oberflächlich prüft: Existiert zu einem addr:street IRGENDWO in der “Nähe” (irgend ein heuristischer Wert) ein highway=* mit dem selben Namen? Heute brauche ich den OSM Inspector für Adressen nicht mehr, da mein Osmosis Plugin die selben Fehler findet. Zusätzlich findet es aber noch andere Fehler (dank der zusätzlichen Redundanz), die der OSM Inspector nicht findet, weil ihm diese Redundanz fehlt (oder genauer: er sie nicht benutzt).
Technisch gesehen sind wir in der OSM auf einem sehr niedrigen Niveau was die Fehlererkennungsmöglichkeiten betrifft. Ich vergleiche es gerne mit einer mittelalterlichen Buchhaltung. Dort konnten Fehler nur erkannt werden wenn sie offensichtlich blödsinnig sind (Eisenbahn am Nordpol) oder wenn man die gesamte Buchhaltung noch einmal durch gerechnet hat und zum selben Ergebnis kommt (2. Survey). Mit der Erfindung der doppelten Buchhaltung wurde jede Buchung 2 mal in verschiedene Konten eingetragen (Redundanz). Auf diese Weise konnten Rechenfehler einfach erkannt werde.
Eine Buchhaltungsprogramm bräuchte heute keine redundante Berechnung mehr, da der Computer sich i.A. nicht verrechnet.
Aber in der OSM gibt es meines Wissens bisher noch kein Tool, dass die Sematik (Bedeutung) der Daten “versteht”. Daher ist die Redundanz für mich derzeit das einzige Mittel Unstimmigkeiten in den Daten aufzudecken. Und im Gegensatz zur Buchhaltung hat OSM ein weiteres Problem: Die Daten ändern sich mit der Zeit und können eigentlich nie vollständig korrekt sein.
Ich bin mir sehr bewusst, dass dies nur funktioniert, wenn jemand (in diesem Fall ich) regelmässig Unstimmigkeiten auswertet und korrigiert.
Übrigens: All die netten OSM Inspector und KeepRight! Auswertungen funktionieren nur durch Redundanz, da ansonsten “dumme” automatische Systeme keine Aussage über richtig und falsch treffen können. Zugegeben, häufig sind die redundanten Informationen nur allgemeine Regeln.
So und nun mache ich mich daran, die 50% Marke bei den erfassten Adressen in Winterthur zu knacken…
Und wie funktioniert dein System bei dem falsch eingetragenen Eckhaus? Ich meine, es gibt ja zwei Möglichkeiten, wie es falsch eingetragen wird: Entweder, deine Information (oder deine Interpretation deiner Information zum Zeitpunkt des Eintragens) ist falsch. Dann wirst du aber beide Werte falsch eintragen und bist dir beim Durchschauen absolut sicher, dass es korrekt ist. Die andere ist, dass du tatsächlich das falsche Haus auswählst, während du entweder den Tag oder die Relation anbringst. Keine Ahnung, wie oft dir das passiert, aber angenommen deine Fehlerquote ist x (0<x<1) und korrekt wählst du dann mit der Quote y=1-x. Es gibt vier mögliche Fälle: Du trägst beides korrekt an, mit Wahrscheinlichkeit y², du trägst beides falsch an x², die Relation stimmt und das Tag nicht xy und der Tag stimmt aber die Relation nicht xy. Von deinen x²+2xy Fehlern kannst du nur 2xy erkennen (denn bei den anderen stimmen die Informationen ja überein) und xy wären garkeine Fehler, wenn du keine Relation hättest (weil das die mit korrektem Tag sind). Bleibt ein Anteil von xy an deinen Eintragungen, die du als falsch erkennen kannst. Das sind maximal 25% (wenn deine Fehlerquote 50% wäre, wovon ich nicht ausgehe), eher deutlich weniger. Und in diesem Fall hättest du noch 25% Fehler, die du nicht erkennst. Der Nutzen ist also zumindest fragwürdig, im Zweifelsfall hilft eben doch nur die 2. Survey, die sowohl die von vornherein falschen Informationen als auch die Doppelfehler finden kann.
Was mir aber nicht ganz klar ist: addr:street ist nach wie vor auf dem Node/Way eingetragen und nicht in der Relation. Wenn ich aber bei jedem Haus sowieso addr:street eintragen muss, um eine komplette Adresse zu erhalten, dann kann ich auch gleich alles da eintragen. Eine Relation würde für mich vor allem Sinn machen, wenn ich diese Information in der Relation eintragen könnte anstatt mit jedem Haus.
Das ist ja gerade der Clou: Da du die Straßen als street in die Realtion packst, nimmt die Adressensuchmaschine den name-Tag der Straße zur Benennung der Straße. Theoretisch könntest du auch den addr:street Tag als Relation Attribut hinzufügen. Ich weiß aber nicht, ob das schon ausgewertet wird. Man hätte damit auf jeden Fall wieder eine zusätzliche Redundanz. Die anderen addr:tag Attribute sind auf jeden Fall am besten als Attribute bei der Relation aufgehoben. Zumindest nominatim wertet diese Tags aus.
Hier würde ich das ganze proposal als approved interpretieren.
Und hier gebe ich dir recht, da ist die Relation nicht erwähnt.
Ich habe deshalb versucht die Abstimmung nachzuvollziehen. Diese soll zwischen 1. und 31. Dezember 2008 stattgefunden haben. Ich habe aber die Resultate nicht gefunden. Auch wurde am Proposal nach dieser Zeit noch fleissig weitergearbeitet. Bei mir kommt deshalb die Frage auf, wieso dieses Proposal den Approved-Status erhalten hat?
Bin deiner Meinung, sämtliche addr-Attribute, welche auf der gesamten Strasse identisch sind (auch addr:street) gehören in die Relation und nicht auf die nodes/ways. Ansonsten macht die Relation keinen Sinn (ausser Redundanz, falls gewünscht).
Der von Tordanik genannte OSM Inspector, aber auch OpenRouteService verstehen name und/oder addr:street in der Relation nicht.
