Simon is being much more polite and succinct than my first reaction. Checking the addr:city against the enclosing administrative boundary will not work well in the areas I am familiar with.
Let me give some examples from the western United States: • The “town” I lived in growing up was Tucson, Arizona. It was used in our mailing address. It was used for emergency response. It was given in directions to our house. Except we lived about 20 KM outside the incorporated boundaries of the City of Tucson and our area was administered by Pima County. • In the San Fernando Valley area of the Los Angeles metropolitan area you have a bunch of named areas, some having relatively distinct boundaries: Granada Hills, Chatsworth, Northridge, Van Nuys, etc. Those are the postal “town” names even though they are not administrative areas for anything other than delivery of goods and services to the addresses therein as they are officially part of the City of Los Angeles and administered by the City of Los Angeles. And don’t confuse those “towns” with Burbank, San Fernando, etc. also in the San Fernando Valley, which are separately incorporated real cities for real administrative boundaries. • The “town” of Oracle, Arizona where my parents moved when they retired isn’t really a town even though it has a post office, a sheriff’s substation and even a regional county administration building with the name “Oracle” on it. It is an “unincorporated” area administered by the Pinal County (county seat is in Florence about 150 KM away). And it has no distinct boundaries. Heck, even “Biosphere II” which is promoted as being in Oracle is about 10 KM from the centroid of houses that are considered to be “in” Oracle. Oracle is another interesting case in that there is no local mail delivery: Residents are given a free postal box at the Oracle Post Office. The street addresses, including addr:city, are used for other delivery services (FedEx, UPS, etc.) and for emergency response (fire, ambulance, sheriff). So addr:city values there can’t even be considered as postal city values. They just “are”. There is no administrative boundary, no nothing. Except you need that information if you are going to give directions or hope that a call for emergency services results in people getting to the correct location. This is even more misguided than the recently added validation check nagging you to put a “segregated” tag on multipurpose paths that allow both hikers and (mountain) bicyclists: The back country trails here vary between 1 meter (if we’ve done “trail maintenance” recently) to maybe 10 cm if it has been a while since our teams have been able to get to that section. Adding “segregated” to the list of tags for a back country trail is just noise around here. At least “segregated” on a multipurpose backcountry path is only noise. Checking “addr:city” against the enclosing administrative boundary will do real harm if mappers “correct” things to “fix” the reported mismatches. Cheers, Tod > On Jun 30, 2020, at 5:38 AM, Simon Poole <si...@poole.ch> wrote: > > Signed PGP part > IMHO addr:city is the "postal" city at least for countries that have such a > concept. With other words validating the tag against admin boundaries is > fundamentally flawed to start with and will only work in the cases in which > admin entity and postal city just happen to have the same name (in the > country I'm resident in there are nearly no post code boundaries that are > exactly the same as the administrative boundary with the same name). > > Simon > > Am 30.06.2020 um 13:59 schrieb Florian Lohoff: >> Hi, >> i am running some address validation pipeline as others do aswell. In >> Germany we have the case that most of the time the addr:city >> on the addresses matches the name on the admin_level 8 boundary >> (Sometimes admin_level 6). >> >> So normally you have: >> >> boundary=administrative >> admin_level=8 >> name=Gütersloh >> >> And all addresses carry a >> >> addr:city=Gütersloh >> >> Now there are some exceptions. One example i always paint red in the >> validator is 33428 Marienfeld. >> >> For Marienfeld there is an admin_level=8 which carries the >> name=Harsewinkel which is correct for all "suburbs" or villages >> belonging to Harsewinkel except Marienfeld. >> >> Marienfeld itself carries a admin_level=9 >> >> So i'd like to have a place in OSM where i store this exceptions >> information (There are plenty other places which have this >> exception). >> >> So i would propose to set an "addr:city=Marienfeld" on the admin_level=9 >> boundary. So the address validator knows that addresses contained within >> this al9 should carry a different addr:city than they normally would >> using the al8. >> >> Other ideas? >> >> Flo
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
