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
Ist halt die Frage, woher die Daten im germany-polygon stammen und wie “scharf” das ist.
Achtung: es gibt eine ganz schlimme Falle, die mir zur Zeit auch Probleme macht.
Relationen mit type=multipolygon “erben” die Tags des Outers und das kann katastrophal sein. So werden z.B. aus falschen TMC-Relationen plötzlich Admin-Grenzen.
Beispiel: https://openstreetmap.org/relation/62722 wird durch osm2pgsql ein Grenzpolygon:
select each(tags) from planet_osm_polygon
where osm_id=-62722;
each
---------------------------------------
(boundary,administrative)
(old_name,Müritz)
(way_area,0.232755)
(admin_level,7)
(TMC:cid_58:tabcd_1:Class,Area)
(TMC:cid_58:tabcd_1:LCLversion,8.00)
(TMC:cid_58:tabcd_1:LocationCode,551)
nur weil manche Outer-Member mit boundary=administrative, admin_level=x getaggt sind. Dieses Tagging ist ja durchaus üblich.
Glücklicherweise hat der Mapper keinen Namen vergeben, dann wäre das durch mein Filter für die Boundaries-Analyse gerutscht.
Nachher werde ich aus type=multipolygon type=TMC machen und dann ist das hier gefixt. Bei AL6 gab es das Gleiche 3x.
Vorhin musste ich übrigens den Thüringer Landtag ändern, der als MP-Building mit admin_level=4 erfasst war. Schwupps hatten wir 17 Bundesländer
Das Ganze ist ein Problem wie osm2pgsql mit echten Multipolygonen (type=multipolygon) umgeht.
Gruss
walter
So, jetzt habe ich auch mal so einen hübschen Fall, wo sich die Ansichten der Verwaltung (sowie aller normaler Menschen) und der Deutschen Post deutlich voneinander unterscheiden.
Der idyllische Weiler Stocksberg ist ganz einfach ein Ortsteil von Beilstein, sodass man (= ich) addr:city=Beilstein, addr:suburb=Stocksberg erwarten würde. Da mir aber jemand vor Ort gesagt hat, dass die Post als Anschrift „Stocksberg“ bevorzugt, und auch der PLZ-Server „Stocksberg, Gem Beilstein“ als Ortsname ausgibt, habe ich brav addr:city=Stocksberg, Gem Beilstein getaggt. Natürlich meldet OSMsuspects diese Adressen nun als suspekt – ganz zu recht.
Was soll ich jetzt am besten tun? Alle Adressen einzeln in OSMsupects „als korrekt markieren“, damit niemand anderes voreilig die Adresse korrigiert? OK. Oder doch, wie das jeder vernünftige Mensch erwarten würde, alles in addr:city=Beilstein umtaggen und die Postler ihren Unsinn selber erledigen lassen (sie haben ja noch die PLZ als Hilfe)? Letzteres würde ich ja bevorzugen, aber wenn addr:city=* wirklich die postalische Anschrift wiedergeben soll, dann muss ich diesen Unsinn addr:city=Stocksberg, Gem Beilstein wohl lassen, oder?
Kurioser Fall. Ich habe erstmal alle 55 Adressen mit addr:city = “Stocksberg, Gem Beilstein” in der Datenbank als korrekt markiert - wenn Anwohner und Post meinen, dass das so korrekt wäre… Wenn gewünscht, mach ich das wieder rückgängig.
Edit: https://osm-suspects.gbconsite.de/map#16/49.0692/9.4092/osm-wrongcity-falsepositive
Vielen herzlichen Dank!
Tja, wenn die Post es sich anders überlegt … Habe gerade nochmal probiert: Wenn man in der PLZ-Suche irgendeine gültige Adresse aus dem Ort zusammen mit „Beilstein“ als Ort eingibt, also z.B. „Beilstein“/„Talblick 4“, findet die Suche gar nichts. Krass! Nur mit „Stocksberg“ als Ort klappt es. Die Post scheint also wirklich auf ihrer Auffassung zu bestehen …
Seit gestern funktioniert der JOSM-Aufruf bei nicht mehr. Ist denn was geändert worden und was kann ich tun? Die seitenweise Tips hier funktionieren bei mir nicht oder ich hab was überlesen. Es kommt nur die Meldung “Ist JOSM gestartet?”
Gruß Thomas