Der Ansatz, Taginfo dazu heranzuziehen, klingt erstmal nicht schlecht.
Allerdings sehe ich da immer noch ein Problem:
Der häufigste operator-Wert alleine hilft ja nicht, um Fehler zu
erkennen; es müsste eine Art Gruppierung her, die auch taginfo bisher
eben nicht bieten kann.
Also:
Telekom, Deutsche Telekom, Telekom AG, Deutsche Telekom AG, Telecom.....
müssten alle auf einen dieser Begriffe abbilden, aber eben nicht auf
irgendwas, das so ähnlich klingt, aber ein völlig anderes Unternehmen
bezeichnet.
Taginfo kann nur Häufigkeiten von Begriffen analysieren und den
häufigsten zurückgeben; nicht aber die korrekte Gruppierung synonymer Werte.
Gruß
Peter
Am 11.06.2011 08:15, schrieb Philip Gillißen:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hallo fly, hallo Martin!
Martin: ich finde deine Idee unterstützenswert, aber ich kann leider
auch Frederiks Einwände verstehen. Eine solche Datenmenge würde die
Komplexität sprengen. Dann könnte OSM schnell zu einer Datenbank für
alles werden, was sie vom Grunde aus nicht ist.
Dennoch würde ich gerne solch ein "Stammdatenkonzept" in OSM sehen, denn
ich überlege jedes Mal, was ich bei operator= setzen muss und schaue
dann nur bei Tagwatch nach, welche Schreibweisen verbreitet sind.
Am 06/10/11 14:38, schrieb fly:
Ich denke ein Ansatzpunkt ist auch sich für verbreitet operator=* zu
einigen und dafür eine Datenbank zu erstellen. Ob im wiki oder extern
ist ersteinmal egal, jedoch sollte sie im wiki verlinkt sein und die
Editor-Software sie benutzen (presets, known values, autocompletion).
Deine Ausführung würde bspw. einen REST-WebService darstellen, der alle
möglichen Werte für Operator beinhaltet. Wenn man nun die "Pflicht",
einen Operator aus dem gültigen Bereich raushält, könnte man als
Datenbasis doch direkt die Tagwatch-Datenbank verwenden, oder?
Sie bietet alle Werte, die bisher ausgewählt wurden als operator und
gleichzeitig unterstützt sie die Wahl durch die Priorität (~=
Verwendungshäufigkeit).
Durch eine Anbindung (und geeignete Datenaufbereitung), würde für mich
bereits ausreichen, wenn die Vorschlagswerte aus Tagwatch aufbereitet im
JOSM/Potlatch 2 angezeigt würden.
Dies hätte den Vorteil, dass die OSM-Datenbank nicht gesprengt wird, die
Daten sich langsam durch jeden Edit verbessern und keine großartigen
Umstellungen notwendig sind.
Ich könnte mir solch eine Lösung gut vorstellen, als naiver Nutzer. Ich
kann nicht beurteilen, ob das Datenmodell von Tagwatch solch eine
Funktion überhaupt anbieten könnte und wie viel Arbeit dies darstellen
würde.
Auf Seiten JOSMs/Potlatchs kann ich mir eher vorstellen, dass die Arbeit
nicht sehr groß ist.
Nur meine zwei, drei Gedanken zu dem Thema.
Gruß,
Philip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3zCAQACgkQYNYFUFLXAD1lPwCfRutrLU0/Cpr7MK96tj8qKjgI
oMcAoIQB4M1/1wi0ZW86IVYaLborxkVA
=bdlC
-----END PGP SIGNATURE-----
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
