Re: [Talk-de] Postalische Eigenständigkeit / admin boundarys

2019-10-17 Diskussionsfäden Florian Lohoff
On Thu, Oct 17, 2019 at 02:03:37PM +0200, Georg Feddern wrote:
> Weder andere noch schöne - eher ein Gegenargument:
> Denn dieses Zusatztagging hilft vielleicht bei solch eindeutigen
> Sonderfällen - aber es bleiben eben immer noch die 0,8 % der anderen
> Sonderfälle, wo Randerscheinungen einfach dem postalischen Zustellbereich
> der Nachbargemeinde zugeordnet werden, die sich nicht so leicht kennzeichnen
> lassen.
> Lohnt sich dann für diese 20%-Erfolgsrate solch eine Sonderlocke?
> Und wenn, dann bin ich voll bei Dir: Für reines QA-Tagging bitte einen qa:
> Namensraum statt allgemeiner keys bitte!
> 
> PS: Kann man das nicht durch einen zusätzlichen QA-Check gegen die
> PLZ-Relation (mit postal_code und name) erkennen/prüfen/false-positiven?

Da bin ich auch fein mit - Wo und wie man das abbildet - qa: namespace
o.ä. Fände das halt nur doof "Ausnahmenlisten" zu pflegen ausserhalb von
OSM - Dann muss das jeder der sich damit beschäftigt wieder selber
machen. Wenn man das irgendwo ablegen kann. 

Das das mit dem addr:city und dem name auf dem Admin Boundary vielleicht
in Deutschland super funktioniert aber woanders kaputt geht ist mir
schon klar.

Die postal_code relation werte ich ja auch aus - postal_code ist ja
identisch für Harsewinkel und Marienfeld 33428 - Aber eben der addr:city
nicht. D.h. der postal_code validiert super - Nur der city name nicht ;)

Deshalb ja auch die mail - mehr an die die sich mit dem QA auf Adressen
beschäftigen. 

1) Wo gibts noch so postalische Sonderlocken?
2) Was ist der schlauste Weg das abzulegen?
3) Wie machen andere das.

Ich kenne halt keine weitere postalische Eigenständigkeit.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Postalische Eigenständigkeit / admin boundarys

2019-10-17 Diskussionsfäden Georg Feddern

Moin,

Am 17.10.2019 um 12:53 schrieb Florian Lohoff:

ich mache so einiges an Adress QA und u.a. überprüfe ich ob das
addr:city zu dem name (und name:suffix) auf dem admin_boundary mit dem
admin level 6 bzw 8 passt.

Das geht auch in 99% der Fälle gut und funktioniert.


Aber nur, weil Äpfel und Birnen (in diesem Fall Verwaltungszugehörigkeit 
und postalische Adresse) genetisch arg eng verwandt sind. ;-)

Es kommt aber eben zu diversen Mutationen.


Es gibt aber einige Gemeinden die im Zuge von Eingemeindungen ihre
postalische Eigenständigkeit erkämpft haben.


Eben - und das ist der wesentliche Unterschied - verwaltungsrechtliche 
und postalische Adress-Zugehörigkeit sind nun mal nicht als identisch zu 
betrachten

.

Z.b. ist hier 33428 Marienfeld genannt (gehört zu 33428 Harsewinkel)

Marienfeld ist eigentlich "nur" ein Stadtteil von Harsewinkel.

https://osm.zz.de/dbview/?db=addresses-nrw=addresserror#51.95246,8.28361,14z

Jetzt suche ich irgendeinen weg wie man das erkennen kann oder halt
entsprechend taggen.

D.h. auf dem admin_boundary mit dem admin_level 10 von Marienfeld
ein addr:city=Marienfeld hinterlassen z.b.

https://www.openstreetmap.org/relation/9609627

Jemand ne andere schöne idee.


Weder andere noch schöne - eher ein Gegenargument:
Denn dieses Zusatztagging hilft vielleicht bei solch eindeutigen 
Sonderfällen - aber es bleiben eben immer noch die 0,8 % der anderen 
Sonderfälle, wo Randerscheinungen einfach dem postalischen 
Zustellbereich der Nachbargemeinde zugeordnet werden, die sich nicht so 
leicht kennzeichnen lassen.

Lohnt sich dann für diese 20%-Erfolgsrate solch eine Sonderlocke?
Und wenn, dann bin ich voll bei Dir: Für reines QA-Tagging bitte einen 
qa: Namensraum statt allgemeiner keys bitte!


PS: Kann man das nicht durch einen zusätzlichen QA-Check gegen die 
PLZ-Relation (mit postal_code und name) erkennen/prüfen/false-positiven?


Grüße
Georg

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de