Personenunabhängig habe ich jetzt auf der Seite einen (pro Besucher einmaligen) großen und deutlichen Hinweis angebracht, dass Änderungen bitte GENAU geprüft werden sollen - so wie es von Anfang an gedacht war. Sollte das in Zukunft nicht ausreichen, muß ich darüber nachdenken, wie “Mißbrauch” vorgebeugt werden kann, z.B. dass man nur noch komplette Areas in JOSM laden kann und nicht nur die “Fehler”, die dann auch noch in JOSM selektiert sind.
Keinesfalls möchte ich, dass OSMsuspects dazu benutzt wird, blind irgendwas in OSM reinzuklopfen, was nicht korrekt ist. Irgendwie bin ich davon ausgegangen, dass so ein Tool eine HILFE geben soll und nicht davon, dass hier Edit-Wars ausbrechen oder stumpf mit Copy’n’Paste gearbeitet wird, ohne sich zu vergewissern, ob das alles richtig ist, was man macht.
Laut Bayrischem Landesamt für Statistik ist die amtliche Schreibweise: “Mühldorf a.Inn”
Verantwortlich ist die Stadt oder der Landkreis, der dies beantragen kann, zumal er offiziell diese auch so verwendet.
Falls ein “Mühldorfer” an dem Schriftwechsel interessiert ist, würde ich ihn per Email weiterleiten.
Die Stadt verwendet offiziell “Mühldorf a. Inn”. Was dem Landesamt wann gemeldet wurde, steht auf einem anderen Blatt.
Bis in den Akten der Stadtratsbeschlüsse nachgesehen wurde , kann ich nur dafür plädieren, beide Schreibweisen aufzuführen, so dass man nur ggf. official_name und xx_name austauschen muss.
Bei mehr als 100 km Abstand halte ich mich da ansonsten raus.
Ich wollte damit nur aufzeigen, das zwischen dem “offiziellen” Namen durch die Stadt, das Landratsamt, das zuständige Landesamt und dem Bundesamt Unterschiede bestehen, die ein “zuständiger Sachbearbeiter” nicht klären kann - nicht von oben nach unten und von unten nach oben nur auf Antrag.
Das Thema “Wie heißt die Stadt wirklich” ist ein vergleichweise junges Thema, da es erst durch den Einzug von Computern relevant geworden ist. Und eigentlich ist es meine Hoffnung, dass Computer bald so schlau sind wie Menschen und erkennen, dass “Mühldorf a. Inn”, “Mühldorf am Inn”, “Mühldorf a. I.” das gleiche bedeuten.
Das können die Computer schon seit mehr als 50 Jahren, man muss es ihnen nur beibringen.
Ein primitiver String-Vergleich ist halt viel einfacher zu programmieren als eine Ähnlichkeitsmetrik (“Meinten Sie vielleicht …”).
select id,:test "test",localname,levenshtein(localname,:test)
from boundaries
where country = 'DEU'
and levenshtein(localname,:test) < 6
order by levenshtein(localname,:test), localname;
id | test | localname | levenshtein
---------+--------------+-----------------+-------------
941004 | Mühldorf Inn | Mühldorf a. Inn | 3
2260843 | Mühldorf Inn | Mühlsdorf | 5
3084045 | Mühldorf Inn | Mülldorf | 5
id | test | localname | levenshtein
--------+-----------------+-----------------+-------------
941004 | Mühldorf an inn | Mühldorf a. Inn | 2
id | test | localname | levenshtein
---------+-----------------+-----------------+-------------
941004 | Mühldorf am Inn | Mühldorf a. Inn | 1
2186929 | Mühldorf am Inn | Nußdorf am Inn | 4
id | test | localname | levenshtein
--------+---------------+-----------------+-------------
941004 | Mühldorf am I | Mühldorf a. Inn | 3
id | test | localname | levenshtein
---------+--------------+-----------------+-------------
941004 | Mühldorf a.I | Mühldorf a. Inn | 3
941054 | Mühldorf a.I | Mühldorfer Hart | 5
2260843 | Mühldorf a.I | Mühlsdorf | 5
3084045 | Mühldorf a.I | Mülldorf | 5
id | test | localname | levenshtein
--------+---------------+-----------------+-------------
941004 | Mühldorf a.I. | Mühldorf a. Inn | 3
Nur wenn die Buchstaben zu sehr auseinander liegen, wird es unsauber - Fuzzy halt.
Hallo Dooley,
ich habe noch eine Frage / Feature Request zu den Listenauswertungen von OSMSuspects:
Dort hast du ja Listen zu den drei Fehlergruppen addr:city, addr:street und addr:postcode,
und in jeder Liste hast du auch eine Spalte “Anzahl”.
Wäre es möglich, dass diese Listen im HTML-Code so darstellbar sind, dass man diese durch Klick auf den Spaltenkopf auf- oder absteigend sortieren kann?
Bei bestimmten Tabellen im OSM-Wiki geht das sehr schön!
Das Handling zu JOSM ist leider nicht optimal, weil mit dem Standard-Aufruf anscheinend die Relations-Elemente nicht geladen werden, hab aber grad eigentlich keine Zeit, da genauer nachzuschauen. Das wird irgendwann gefixt werden, im Moment gehts halt über eine WürgAround-quick’n’dirty-Lösung, weil die Gelegenheit grad gut ist mit der Menge an defekten PLZ-Gebieten
osm_id 1261062499 147545641
addr:housenumber 1 1
addr:street Wittgensdorfer Straße Wittgensdorfer Straße
addr:suburb
addr:country DE
al9
al8 Burgstädt Taura
al7 Burgstädt Burgstädt *2
al6 Landkreis Mittelsachsen Landkreis Mittelsachsen
al5
al4 Sachsen Sachsen
=====> addr:city Burgstädt Taura
*2 Verwaltungsgemeinschaft
Ich habe unter die Fälle die jeweiligen Namen der admin_level der Umschließenden Objekte geschrieben. Meiner Meinung nach sollte der Algorithmus zur Ermittlung des impliziten Inhaltes von addr:city bei admin_level 8 beginnen und den Namen des umschließenden Objektes auslesen. Nur wenn dieser nicht existiert, sollte bei admin_level 7, 6, 5, 4 weitergesucht werden, bis ein Name gefunden wurde.
Ich weiß dass dieser Algorithmus zeitaufwendig sein könnte, aber er muß ja nur zum Einsatz kommen, wenn es notwendig ist den impliziten Namen von addr:city herauszufinden.
Ich wäre Dir sehr verbunden, wenn es Deine Zeit erlaubt, Dir das Problem mal anzusehen.
Vielleicht wäre es auch einfach sinnvoll, komplette Adressen (city, suburb) zu verwenden. Es ist auch für einfache Auswertungen “einfacher” als eine “komplizierte” Abfrage.
@geri-oc:
Das ist bereits jetzt der Fall, das addr:city verwendet wird, wenn es explizit gesetzt ist. Andernfalls ist OSMSuspects! darauf angewiesen, addr:city zu ermitteln, um unterscheiden zu können, ob zwei Adressen bei gleichen Werten addr:street und addr:housnumber im gleichen Ort (addr:city ist auch gleich) liegen und damit ein “bemeckernswertes” Duplikat darstellen oder eben nicht.
Diese Überprüfung ist aufgrund eines Hinweises von mir (siehe Posting #283 in diesem Thread) von Dooley dankenswerter Weise eingeführt worden.
Hier geht es nun darum, den benutzten Algorithmus nochmals zu optimieren. Natürlich könnte man diese 3 Fälle auch “lösen”, indem man addr:city einfach setzt, aber das wäre erstens eine Art Mapping zwar nicht für den Renderer sondern für den Qualitätssicherer und zweitens wäre es natürlich besser, diese false positives gar nicht anzuzeigen, wenn das mit vertretbarem Aufwand vermeidbar wäre.
+1:
Der “postalische Ortsname” weicht nicht selten vom administrativen ab, bzw. umfasst andere Gebiete.
Das explizite Setzen von addr:city erhöht also die Datenqualität und ist dann nicht einmal Redundanz.
Es ist mMn damit kein “false positive”.
Außerdem kommt es den Nutzern entgegen, die an den Häusern/POIs “unbedingt!!!” die volle Adresse haben möchten.
Ich habe mir am Wochenende nochmal die dupes-Erkennung genauer angeschaut und dabei einen kleinen Bug gefixt, daher ist die dupes-Anzahl seit heute etwas gestiegen.
Was nicht geht, wenn in keiner der Vergleichsadressen ein addr:city gesetzt ist, also genau die Fälle, die du in deinem vorherigen Post https://forum.openstreetmap.org/viewtopic.php?pid=647023#p647023 aufgezählt hast.
Ich bin (wahrscheinlich zum Leidwesen von dir) eine der Personen, die unbedingt komplette Adressen am Objekt haben wollen aus den Gründen, die geri-oc und seichter genannt haben. Daher geht mein Motivationlevel, an der dupes-Erkennung in dieser Richtung weiterzuschrauben, gegen Null.
Ich habe die Prüfkriterien für die Hausnummern etwas strenger ausgelegt, damit auch Einträge wie “0”, “12 u. 13”, “30 | 1”, “12, 14” etc. gefunden werden, über die ich gestern gestolpert bin.
Danke! Das könnte zwar Diskussionen geben, weil mancher einer „12, 14“ für völlig richtig hält, aber es ist sicher richtig, so etwas anzumeckern – man muss es ja nicht ändern.