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 
Hallo Dooley,
ich habe leider nochmal in der Auswertung der doppelten Adressen false positives entdeckt:
osm_id 1345088286 93190640
addr:housenumber 10 10
addr:street Limbacher Straße Limbacher Straße
addr:suburb
addr:postcode 09337 09224
addr:country
al9 Grüna
al8 Hohenstein-Ernstthal
al7
al6 Landkreis Zwickau Chemnitz *1
al5
al4 Sachsen Sachsen
=====> addr:city Hohenstein-Ernstthal Chemnitz
*1 kreisfreie Stadt
osm_id 3282124445 566641087
addr:housenumber 35 35
addr:street Obere Hauptstraße Obere Hauptstraße
addr:suburb
addr:country
al9
al8 Hartmannsdorf Niederfrohna
al7 Limbach-Oberfrohna
al6 Landkreis Mittelsachsen Landkreis Zwickau
al5
al4 Sachsen Sachsen
=====> addr:city Hartmannsdorf Niederfrohna
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.
Vielen Dank,
viele Grüße JSe
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.
M.E. ist es detailliertes Mapping - also genaues erfassen der (addr:=) Daten.
Also nicht mappen für den Renderer, Qualitätssicherer, …
+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.
Gruß, Frank
Moin.
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.
Gruß, Frank
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.
Moin,
werden bei den Dupes nicht mehr die unterschiedlichen addr:city (explizit am Objekt gesetzt) berücksichtigt?
Grüße, Georg
Hat evtl. am Wochenende nur ein größerer/anderer Bug den kleineren bug gefressen?
Hmpf. Du hast recht, da scheint irgendwas mit der Erkennungslogik nicht mehr zu stimmen. Da muß ich wohl nochmal ran.
Edit: Die dupes werden für die nächsten ca. 30 Minuten nicht zur Verfügung stehen, ich generiere die grade neu.
Edit 2: So, sollte gefixt sein. Danke @GeorgFausB, für den Hinweis.
Sorry, aber so ganz passt das jetzt nicht, weil Adressen wie “1 1/2”, also mit Leerstelle und nachfolgendem Bruch, verbreitet völlig korrekte Hausnummern sind (zum Beispiel in Augsburg oder Greding).
Danke, habe es heute nacht noch gefixt.
Hallo dooley,
ein Fehler, den OSMsuspects (noch?) nicht bemerkt:
Ich hatte z.B. an diesem Gebäude - duch Kopieren - den falschen Teilort eingetragen:
https://www.openstreetmap.org/way/501031567/history
Grüße aus Oberschwaben
Peter
Das ist richtig, addr:suburb wird nicht geprüft. Die entsprechenden administrativen Einheiten sind oft nicht in OSM als Fläche verfügbar. In Zahlen haben wir nur 4983 x admin_level 9, 4450 x admin_level 10 und 1055 x admin_level 11 als boundary in Deutschland erfasst. Das ist meiner Meinung nach viel zu wenig, um es sinnvoll auszuwerten. Bei viel Freizeit mach ich mal einen Testlauf, um da Erkenntnisse zu gewinnen.
Komisch, ich komme auf ganz andere Werte:
wno_number | count
------------+-------
2 | 1
4 | 16
5 | 19
6 | 399
7 | 1258
8 | 11164
9 | 4762
10 | 4157
11 | 1016
12 | 164
magst du mir mal deine Query zeigen? auch gerne per PN oder Mail.
Gruss
walter
select count(*), admin_level
from public.germany_polygon
where admin_level::numeric between 9 and 11
and boundary = 'administrative'
group by admin_level
order by admin_level::numeric asc;
Ich schliesse nicht aus, dass da ggf. ein paar dabei sind, die nicht zu Deutschland gehören bzw. durch osm2pgsql Relationen aufgelöst wurden und damit mehrfach gezählt werden. Ich hab die Zahlen nur mal als Anhaltspunkt genommen ohne Gewehr auf 100% Genauigkeit.
Gruß, Frank