FahRadler und ich haben noch ein bisschen weiter geschrieben, einerseits in einer Changeset Diskussion, andererseits auch per PN, wo er folgendes geschrieben hat
D.h. er hat es überwiegend gut gemeint.
Ich habe ihn gebeten, sich durchaus hier nochmal selbst zu Wort zu melden.
so ähnlich sieht es in einigen Orten im Südwesten Brandenburgs auch aus… https://osm-suspects.gbconsite.de/#13/51.7072/13.4814/osm-wrongcity-wrongstreet-outsideplz deswegen fasse ich da einiges derzeit nicht an.
Da wäre ich dafür, mir fehlt es an Erfahrung, ich traue mich an diesen Riesenbatzen nicht ran.
Sven
Ich sehe das Problem bei den grossen CS, das sagt aber meist nix aus, wieviel Stunden Arbeit welcher Qualität da drin stecken. Ich hab auch grosse CSe in der Vergangenheit gemacht, wo nachvollziehbar schlecht erkennbar ist, wie mechanisch die sind (oder eben nicht). (Deswegen beschränke ich mich mittlerweile bei grösseren auf Bundesländer).
Das beantwortet Deine Frage nicht, die Antwort: ich enthalte mich jetzt, ich wollte nur anmerken, dass es nicht immer nur schwarz oder weiss gibt. (Ich hab bspw. demletzt in Sachsen einen “mechanische-Keule”-Revert gefressen, wo ich als Konsequenz in Sachsen nun keine Öffnungszeiten mehr korrigiere. Kann’s auch irgendwie nich sein…)
Speziell bei mglw./angeblich/bewiesenen mechanischen Edits sollte man imho auch mal 5e grade sein lassen (und/oder genau hinschauen, ob jetzt wirklich die Welt untergeht).
Nachtrag: wg. der Nachprüfbarkeit; ich mach in solchen Fällen ein lokales Revert ohne Upload und schau mir die Daten an. JOSM bekommt 1350MB Ram und das hat bisher locker gereicht für solche Fälle.
Ich habe das so verstanden, dass das Umtaggen OK ist, wenn man es (1) in übersichtlichen Changesets vornimmt, d.h. normalerweise (2) räumlich klar begrenzt, z.B. alle betroffenen Adressen in einer Gemeinde, und (3) am besten nicht bloß mechanisch alle Adressen ändert, sondern die Adressen möglichst einzeln ansieht, um so andere vorhandene Fehler zu bemerken oder zumindest nicht zu „maskieren“. Zumindest sollte man eindeutig „faule Eier“ wie z.B. Mülleier mit Hausnummern bemerken und nicht durch Umtaggen auch noch „adeln“.
Konsens? Dissens?
– snip, sorry –
– snip, sorry –
(4) und diverse andere Sachen, z.B. das für DE/AT/CH ungebräuchliche addr:province entfernt, und (5) sich überlegt was man mit Gebäuden macht, die addr:city/postalcode/country haben, aber kein addr:street/housenumber, und (6) endlich mal geklärt ist, was für eine Adresse wir deutschlandweit überhaupt erfasst haben wollen.
PS: Und ja 1-3 Konsens 
Tja, das wäre freilich wirklich schön! Wahrscheinlich ist das ein unlösbares Problem, solange die Post oft deutlich andere Namen erwartet als die Verwaltung und als „normale Menschen“. Ich hatte jetzt auch mal einen netten Fall. Bei diesem Gebäude und den restlichen Gebäuden des Wohnplatzes scheint die DPAG laut plzserver tatsächlich „Obere Ölmühle 1, 71720 Obere Ölmühle“ zu erwarten; ich bezweifle, dass irgendjemand außer der Post das versteht. Daher habe ich in addr:city „Beilstein“ belassen, was wohl auch alle Bewohner der Umgegend so erwarten würden (da die Obere Ölmühle eben zu Beilstein gehört). Aber gemäß DPAG müsste ich in addr:city vermutlich „Obere Ölmühle“ unterbringen …
Vielleicht müssten wir (mindestens) zwei verschiedene addr:city-Tags einführen, à la addr:admin_city=Beilstein und addr:postal_city=Obere Ölmühle. 
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.
Gruß, Frank
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.
Moosburg und Zolling liegen auch a.d.Isar bzw. a.d.Amper. Es scheint also in der Gegend lokal üblich zu sein, auf die Leerzeichen zu verzichten.
Warum muß ich da nur immer an Otto denken “Zeitersparnis gleich Null - immerhin etwas”
Baßtölpel
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.
“Deutschlands Bürokratie”
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 …”).
Man braucht nicht alles selber zu erfinden: Viele Datenbanken kennen solche Vergleiche:
https://www.postgresql.org/docs/current/static/fuzzystrmatch.html
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.
Gruss
walter
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!
Gruß, Stephan
https://osm-suspects.gbconsite.de/liste/street/A
Ist drin. Die Seite bitte einmal neu laden…
Gruß, Frank
Suuuuuuuuuuuuper !!!
Tausend Dank!!
Aus gegebenem Anlass https://osm-suspects.gbconsite.de/statistic habe ich eine zusätzliche Liste https://osm-suspects.gbconsite.de/liste/boundarypostcode eingebaut, die defekte Postleitzahlengebiete anzeigt.
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 