QS für OSM-Daten

Hier ein “konkreter” Vorschlag für eine “QS-Maßnahme 1 - Inkorrekte Tagkeys”:

QS-Maßnahme:
Ziel: Ermitteln von Tipp-/Rechtschreibefehler in Tagkeys
Start: 01.08.2011
Ende: 30.09.2011
Ergebnis: Liste mit inkorrekten Tagkeys zur allgemeinen Korrektur der OSM-Basisdaten (z.B. via Xybot)

Vorgehensmodell:
Vorgehen: Sammeln der inkorrekten Tagskeys in Form von Listen
Listenaufbau: Inkorrekter Tagkey => Korrekter Tagkey

Organisation:
Datensammlung: Zentrale Sammlung der userspezifischen Einzellisten
Zwischenergebnisse: Veröffentlichung der konsolidierten Ergebnisse auf temporärer Webpage

Bezüglich einer Umsetzung könnte ich die Listensammlung, Konsolidierung und Veröffentlichung der Zwischenergebnisse übernehmen.
Hierzu würde ich eine temporäre Webpage anlegen. Die Korrekturlisten würde ich per eMail-Anhang entgegen nehmen.
Der eMail-Anhang (Name des Anhangs = Username) beinhaltet dann die Korrekturliste im definiertem Format.
Jede eingesandte Liste sollte immer alle Korrekturen beinhalten. D.h. je User gibt es immer nur eine (userspezifische) “finale” Liste.
Die Konsolidierung würde automatisiert via Programm erfolgen.

Finde ich super, wenn wir das angehen würden. Aber wäre eine Wikipage nicht einfacher und für jeden änderbar/einsehbar?

Tolle Sache. Ich helfe gerne mit beim Suchen von Schreibfehlern - keepRight zeigt da auch immer wieder welche an…

Gibt es bereits eine Sammelstelle für diese Fehler? Ich habe bereits eine kleine Liste erstellt…

http://wiki.openstreetmap.org/wiki/User_talk:Xybot

… und vielleicht auch mal eine Mail an xylome (ggf. mit Hinweis auf diesen Thread). Keine Ahnung, wie oft er ansonsten auf die Wikiseite guckt.

Eine Wiki-Page für die Projektbeschreibung und die Projektergebnisse wäre aus meiner Sicht sehr gut. Wer könnte eine solche Seite an der “richtigen” Stelle mit der “richtigen” Struktur anlegen? Ob es allerdings sinnvoll ist, daß jeder seine Teil-/Zwischenergebnisse dort einträgt wäre zu diskutieren. Besser fände ich es, wenn die Teilergebnisse zunächst an geeigneter Stelle gesammelt und dann per Programm konsolidiert würden. Ansonsten sind redundante Einträge sehr wahrscheinlich, da mehrere Personen wohl einige identische Defekte finden dürften. Wie könnte eine solche Sammelstelle aussehen? Ein Programm zur Konsolidierung der Ergebnisse könnte ich wohl schreiben.

Oki doki, hatte gerade Zeit und mich mal drangesetzt.
http://wiki.openstreetmap.org/wiki/User:Xybot/Improvements2011

Ist aber nur was ich mir so als sinnvoll vorgestellt habe. Bin das WE nicht online, ändert das gerne wenn ihr wollt :slight_smile:

Danke fürs Aufsetzen. Ich verstehe allerdings noch nicht so richtig, wie ich dort z.B. folgenden Schreibfehler eintrage: berrier → barrier

Ach verdammt, am besten mit “
” einen Zeilenumbruch machen und das nach dem falschen Ausdruck hinschreiben. Denke so springt einem das gut ins Auge. Beispiel habe ich mal hinzugefügt

Bezüglich der Projekt-Wiki-Page gingen meine Vorstellungen mehr in diese Richtung:

  • Anlegen einer eigenen Wiki-Page für “QS-Maßnahme 1 - Inkorrekte Tagkeys”
  • Einstellen der individuellen Findings durch die Projektteilnehmer
  • Konsolidierung der individuellen Findings zu einem Gesamtergebnis

Die Wiki-Page könnte m.E. wie folgt aussehen:

QS-Maßnahme 1 - Inkorrekte Tagkeys
Ziel: Ermitteln von Tipp-/Rechtschreibefehler in Tagkeys
Start: 01.08.2011
Ende: 30.09.2011
Ergebnis: Liste mit inkorrekten Tagkeys zur allgemeinen Korrektur der OSM-Basisdaten (z.B. via Xybot)

Vorgehensmodell:
Vorgehen: Sammeln der inkorrekten Tagskeys in Form von Listen
Listenaufbau: Inkorrekter Tagkey => Korrekter Tagkey

Organisation:
Datensammlung: Zentrale Sammlung der userspezifischen Einzellisten
Ergebnisse: Konsolidierung der Einzellisten zu einem Gesamtergebnis

Findings konsolidiert (Stand: 06.08.2011):
militry => military
natuarl => natural
touriesm => tourism

Findings User apfel:
natuarl => natural
militry => military

Findings User birne:
natuarl => natural
touriesm => tourism

Mir ist der Unterschied zwischen der Wiki Seite von !i! und Deinem Vorschlag nicht offensichtlich. Pflege die Werte doch einfach ein …

Einzelne Seiten hätte in meinen Augen den Vorteil, dass es übersichtlicher wird. ich würde die Seiten dann aber eher nach Thema trennen (Eine Seite mit Wegeigenschaften, eine mit POIs, etc.). Helfen würde denke ich auch, wenn man vielleicht je eine Tebelle für jeden Key macht und nicht eine rießige.

Konsolidieren kann man das ja aber auch so, ohne für jeden user eine Seite anlegen zu müssen.

Grüße,
Christian

Am besten noch ein "=> " vor der richtigen Schreibweise einfügen. Das macht die Sache hoffentlich eindeutig.

Wenn alle Werte zu einem Schlüssel klein geschrieben werden, sollte eine Regel für alle Werte dafür reichen (Beispiel cuisine).

Übrigens ist die Inanspruchnahme des User-Namensraums Xybot mit xylome dem Betreiber des Xybot abgesprochen? Wenn nicht, empfände ich das als grobe Unhöflichkeit. (Sachlich passt es da hin, wenn man davon ausgeht, dass der Xybot die Arbeit erledigt.)

Edbert EvanE)

Vermutlich wird die Liste der Schreibfeler ziemlich lang.
Deshalb wäre es sinnvoll, diese Liste 2-spaltig, sortierbar und maschinenlesbar zu machen:

{| class=“wikitable sortable”
! richtiger Schlüsse=Wert || falscher Schlüssel=Wert
|-
| highway= || heiwei=
|-
| highway=motorway || highway=autobahn
|-
| … || …
|}

Durch die Sortierbarkeit können Doppelungen und andere Fehler in der Liste gefunden werden.

Im Sinne einen guten Qualitätsmanagementes wäre es natürlich sinnvoll, solche Falscheinträge in die DB gar nicht erst zuzulassen.

Beispielsweise könnten die Editoren Tippfehler gleich zurückweeisen: “Einen Schlüssel ‘heiwei’ gibt es nicht. Meinst Du vielleicht ‘highway’?”
Und als Antwortmöglichkeit: a) “Ja, ich meine ‘higway’” oder b) “Nein ich möchte einen neuen Schüssel ‘heiwei’ anlegen”.
Für b) wird dann ein entsprechender Prozess beschrieben (aber das wäre ein neuer Thread).

Ist es eigentlich immer noch jedermann erlaubt, per Konsole direkt in die DB zu schreiben?
Dagegen könnte eine Zwischenschicht in der DB helfendie solche Einträge abfängt und nur dann an die DB weiterleitet, wenn sie syntaktisch geprüft/korrigiert sind. Unklare Fälle müssten wie im Editor an den Benutzer zurückgewiesen bzw gemäss einem definierten Prozess bearbeitet werden.

Gruss, Markus

Eine programmtechnische Konsolidierung der Findings wäre auch aus meiner Sicht unbedingt erforderlich.
(Auch) Deshalb sollten die von den Projektteilnehmer erstellten Listen möglichst einfach sein.
Vorschlag siehe oben.

Ah ok, nun ich habe mich probiert auf die Erstellung eines Reports zu beschränken, schlichtweg weil ich wenig Zeit hatte. Du kannst das aber sehr gerne anpassen/erweitern, das ist ja ein Wiki :slight_smile:

Wir sollten vlt. auch den XYBot Autor nochmal fragen wie er das gerne hätte (hatte sich bei mir leider nicht zurückgemeldet). Das parsen einer einzelnen Seite ist aber in der Regel einfacher. Aber wie gesagt, passt das gerne an, die nächsten Tage habe ich fafür keine Zeit :frowning:

Wir haben doch eine liste aller Keys, kann man darauf nicht auch eine phonetische Ähnlichkeitssuche mal machen, um Schreibfehler zu entdecken?

Im Zusammenhang mit Problemen bei der Adresssuche für Garminkarten hat Georg V. (user_5359) eine OSM-DB-Auswertung über alle admin_level erstellt.
In der Auswertung werden alle existierenden Bezeichnungen / Namen jedes admin_level gelistet.
Möglicherweise ist es sinnvoll die Benennung einmal auf Einheitlichkeit zu prüfen.
Die Liste liegt im Excel-Format vor und kann hier runtergeladen werden: http://www.easyclasspage.de/karten/files/AdminLevel_DE.xls.zip

Gruß Klaus

PS: Wie weit sind wir eigentlich seit dem Sommer mit dem Thema “QS bei inkorrekten Tags” gekommen?

So, ich grabe diesen 1.5 Jahre alten Thread mal aus … Warum ?

… weil es mittlerweile neue Tools gibt, mit denen sich eine QS hervorragend durchführen läßt:

  • overpass-api
  • overpass-turbo

Nun zur Idee - dargestellt an einem Beispiel …
Ich möchte in meiner Homezone alle “tracks ohne tracktype” finden (die es nach meinem Verständnis nicht geben sollte).

Schritt 1: Datenabfrage formulieren.
/* tracks ohne tracktype */
way [highway = track][tracktype !~ ‘.’] ({{bbox}}); (._;>;); out meta;

Schritt 2: Overpass-Turbo aufrufen.
http://overpass-turbo.eu/

Schritt 3: Homezone auf der Karte auswählen.

Schritt 4: Datenabfrage einkopieren und ausführen.

Schritt 5: Ergebnis prüfen und …

Screenshot wie es final aussehen sollte:

Gruß Klaus

Wird aber auch bei keep_right angezeigt.

Wichtig wäre: Jeder sollte in seinem Bereich ab und zu einmal die QS nutzen.