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.
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.
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
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.
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.)
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.
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
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
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;