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).
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.
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.
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.
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.
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.
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?”
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.
Am 18.08.2017 waren 13.001.190 Objekte mit Adress(bestandteil)en für Deutschland erfasst, davon 10.317.091 out of the box benutzbar. Jemand ne Idee, wieviel Adressen es in Deutschland insgesamt gibt (circa)?