OSMSuspects - Qualitätssicherung Adressen (Deutschland)

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? :wink:

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.

@dooley

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 :wink:

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. :wink:

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 … :wink: 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

Lade dir mal ein Objekt im Browser. Z.B https://127.0.0.1:8112/load_object?new_layer=true&objects=w48889512
Dann sollte der Browser dich nach dem Zertifikat fragen. Zustimmen und dann sollte Josm wieder flutschen.

Gruss
walter

An der Website wurde seit mehreren Wochen nichts geändert. Hast du eventuell Browser, JOSM etc. upgedatet?

Da kommt: Fehler: Verbindung fehlgeschlagen Firefox kann keine Verbindung zu dem Server unter 127.0.0.1:8112 aufbauen. Beim zweiten Mal gehts, allerdings erzählt Firefox mir, dass ich schon eine Ausnahme für die Seite hinzugefügt habe und die Verbindung nicht sicher wäre und ob ich die Ausnahme entfernen soll. (Wenn ich auf das Schlosssymbol gehe mit dem gelben Ausrufezeichen)

Browser wahrscheinlich. JOSM hab ich vermieden, weil das Kendzi3D-Plugin nicht mehr funktioniert.

War was anderes. FF-Plugin U-Block Origin hatte OSMSuspects! und overpass turbo blockiert, obwohl ich es mal irgendwann erlaubt hatte.

Heute geht einzelne Objekte laden nicht mehr. Aktuelle Ansicht in JOSM laden dagegen schon.

Gruß Thomas

Bei mir Null Problemo.

Welcher Josm? bei mir josm-tested 12450
Fehlermeldung?
Konsol-Log?

Gruss
walter