[Talk-at] Lizenzwechsel

[Friedrich Volkmann]

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