On 02.03.2012 13:37, Frederik Ramm wrote:
On 03/02/2012 12:45 PM, Friedrich Volkmann wrote:
ich lasse mir ja einreden eine Regel, dass das name-Tag gelöscht wird,
wenn soundsoviel % des Wertes und eine bestimmte Mindestlänge identisch
ist.
Hab ich auch schon drueber nachgedacht, seh ich aber nicht. Zum Beispiel ist
die Aenderung "Bachstr." -> "Bachstraße" 1 Zeichen geandert und 2
hinzugefeugt; die sehr viel schwerwiegendere Aenderung "Bachstraße" ->
"Talstraße" ist auch nur 2 Zeichen geandert und 1 geloescht.
Wenn die Talstraße verloren geht, ist das immer noch besser als wenn ALLE
geänderten Namen verloren gehen.
In dem Beispiel hast du nur die Anzahl geänderter Zeichen berücksichtigt,
nicht den %-Satz. Es wurden 40% geändert, das ist doch ziemlich viel. Ich
würde den Grenzprozentsatz etwas niedriger ansetzen, vielleicht bei 25%.
Dann geht die Talstraße gar nicht verloren.
In der Bachstr. kommt ein Punkt am Ende vor. Bei einem Punkt am Ende oder
vor einem Whitespace kann man von einer Abkürzung ausgehen. Auf diese Weise
lässt sich die Gleichheit von Bachstr. und Bachstraße automatisch feststellen.
Und wie Du in einem anderen Beitrag richtig geschrieben hast, sollten wir
wohl kaum irgendwelche Spezialregeln fuer spezielle deutsche Worte einbauen.
Ich habe nur drauf hingewiesen, dass Spezialregeln für deutsche Wörter nicht
die anderssprachigen Wörter abdecken. Das heißt nicht, dass diese Regeln
schlecht sind. Besser ein Feintuning für deutsche Wörter als gar keins.
Ich habe den Eindruck, dass Du diese Vorschlaege, die von Dir hier kommen,
der LWG wegen Unausgegorenheit links und rechts um die Ohren hauen wuerdest,
wenn sie von dort kaemen ;)
Kann schon sein, dass sie unausgegoren sind, aber was die LWG bisher
geliefert hat, ist noch viel unausgegorener.
Fakt ist, dass nicht *jede* Aenderung an einem Namen den Beitrag des vorigen
Mappers ausloescht, selbst wenn *manche* Aenderungen an einem Namen dies
vielleicht tun. Wenn wir einen guten Automatismus faenden, der diese Faelle
wenigstens grob auseinanderhaelt, koennten wir den eventuell einsetzen.
Ich erweitere mal den obigen Ansatz:
Von den im Wiki dokumentierten und anderen häufig verwendeten Keys muss eine
Liste erstellt werden, welche dem Wesen nach Freitextfelder als Werte haben
und welche diskrete (im math. Sinn) Werte. Z.B. name, description, note*,
source*, ref, *:ref, addr:*, operator, website, url, opening_hours sind
Freitext-Tags, hingegen haben amenity, natural, landuse, highway diskrete Werte.
1.) Freitext-Tags:
A) website, url: alles außer der Domain wegschneiden (also http://, Pfad und
Query-String). Wenn Werte nun identisch, übernehmen, sonst löschen
B) source: muss immer übernommen werden
C) source:<tag> muss dann übernommen werden, wenn auch <tag> übernommen wird.
D) ref: Whitespaces und punct.characters wegschneiden. Wenn nun identisch,
dann übernehmen, sonst löschen.
E) sonstige:
erster Schritt: Schreibung standardisieren (Umlaute auflösen, diakritische
Zeichen entfernen usw., siehe Mail von Boris)
zweiter Schritt: Prüfen ob Abkürzungspunkt (vor Whitespace oder Ende) im
einen Wert mit zusätzlichen Zeichen im anderen Wort korreliert. Wenn ja,
dann auflösen.
dritter Schritt: Whitespaces und einleitende/abschließende Sonderzeichen löschen
vierter Schritt: wenn mind. 80% der Zeichen übernommen wurden => Wert gilt
als übernommen, sonst als ersetzt
2.) "diskrete" Tags:
Hier gelten andere Regeln! Denn z.B. tracktype=grade5 und grade4 sind keine
verschiedenen Schreibweisen für einen Wert, sondern haben verschiedene
Bedeutungen. Außerdem muss die Aneinanderreihung mit Strichpunkt
berücksichtigt werden. Daher:
erster Schritt: Wert an Strichpunkten zerlegen, Teilwerte von einleitenden
und abschließenden Whitespaces befreien
zweiter Schritt: jeder neue Teilwert, der auch als alter Teilwert vorkommt,
ist zu löschen. Die übrigen bleiben.
3.) Seltene Keys:
Weiß nicht. Sie sind entweder wie (1) oder wie (2) zu behandeln.
Komplizierter wird es, wenn in der History ein Key von einem Zustimmer
gesetzt wurde, von einem Ablehner geändert und von einem Zustimmer nochmal
geändert. Dann muss der neue Wert nicht nur mit dem des Ablehners, sondern
auch mit dem davor verglichen werden.
Mein Bauchgefuehl ist, dass es wesentlich haeufiger vorkommt, dass man einen
Namen leicht verbessert, als dass an einen existierenden Namen komplett
durch einen selbst ermittelten ersetzt. Wenn Du hier davon sprichst, dass
"deine Arbeit vernichtet" wird, dann scheint das bei Dir ja anders zu sein.
Oder denkst Du an ein anderes als das Name-Tag?
Was ich oben "diskrete" Tags genannt habe, muss man sowieso anders behandeln.
Betreffend name: Wir haben in AT viele von plan.at importierte Straßen, die
ursprünglich den Ortsnamen als Straßennamen hatten. Wenn ein Ablehner die
Straße gesplittet hat, war am neuen Way der falsche Name, mit dem Ablehner
als scheinbarem Urheber. Ich hab keine quantitativen Untersuchungen
angestellt, aber sicher wurden viele dieser Pseudo-Straßenmamen später von
Zustimmern auf den richtigen Namen geändert.
Dass ich odbl=clean behutsam einsetze, weiß ich. Ich weiß aber nicht,
wie behutsam andere es einsetzen. Laut deinem vorigen Mail (»dass bei
einer zu grossflaechigen missbraeuchlichen Verwendung von odbl=clean
durch zu viele Mapper irgendjemand sagt "lieber ignorieren wir
odbl=clean komplett«) bin ich aber davon abhängig, was andere tun.
Ja, schon, aber das sind wir doch hier bei OSM staendig alle. Wenn sich
heute rausstellt, dass vor 2 Jahren jemand halb Wien von Google abgemalt
hat, muss das auch alles raus und es gibt grosses Geheule. In so einem
Projekt wie unserem kann man staendig ohne eigenes Verschulden auf die Nase
fallen. Aber man kann auch selbst durch gutes Vorbild einen Teil dazu
leisten, diese Gefahr zu verringern und ein Klima zu schaffen, in dem andere
genauso sorgfaeltig arbeiten wie man selbst.
Du vergleichst einen hypothetischen, irrealen Fall (dass halb Wien von
Google abgemalt ist) mit einem Fall, der dir und dem Wiki zufolge wirklich
eintreten kann (odbl=yes wird nicht berücksichtigt).
Sorgfältig arbeiten wollen wir alle, aber gerade dafür müssen wir in der IT
die Spezifikationen beachten. Wenn im Wiki steht, dass odbl=yes einen
Error-Status hat und vielleicht nicht berücksichtigt wird, dann erfüllt es
die Anforderung nicht und wir müssen uns nach anderen Metoden umsehen. Z.B.
Objekte zu löschen und neu anzulegen.
On 02.03.2012 13:45, Frederik Ramm wrote:
Bei Splits ist die Position der LWG, dass das selten genug vorkommt, so dass
man der Sorgfaltspflicht genuegt, wenn man sagt: Wir gehen der Sache im
Einzelfall nach, wenn sich jemand beschwert.
Splits sind sehr häufig, denn sobald man irgendwo eine Brücke oder
Geschwindigkeitsbeschränkung oder einen anderen tracktype einträgt, ist
schon ein Split nötig. Ebenso wenn ein Teil der Straße in eine Relation
gehängt wird. Splits sind sicher häufiger als Namensänderungen.
Als Grund, warum die LWG Splits nicht berücksichtigt, vermute ich eher, dass
es ihnen zu kompliziert ist.
Mir scheint, dass Du mit Deinem lautstarken Beharren auf Gleichbehandlung beider Faelle erreichen
zu koennen glaubst, dass man irgendwann sagt "ach, naja, schaun wir halt ueberall nicht so
genau hin". Das Gegenteil ist wahrscheinlicher: "Hm, ok, dann muessen wir eben doch alle
Splits genau analysieren und die Sachen auch noch loeschen."
Da bin ich zuversichtlich, dass die das nicht schaffen.
Ja, mit Berücksichtigung von Splits wären sicher viel mehr Objekte rot.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
_______________________________________________
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at
