Hi all, User 25or6to4 contacted me offline mentioning that he has been working on improving boundaries based on newer TIGER for the past months now. That, taken together with the boundless (ha) energy exuding from this thread, makes me have a very happy boundary-positive attitude! I’m not much of a boundary editor myself, but fortunately we all have our favorite topics. This community is awesome.
Martijn > On Nov 14, 2018, at 1:02 PM, OSM Volunteer stevea <stevea...@softworkers.com> > wrote: > > Carl Anderson is correct: what is in the map from TIGER about LSAD is true > and affords the possibly to derive geo data about incorporated entities (in > some cases, where they haven't been deleted), although the data (being > somewhere between 11 and 13 years old) may not be accurate, given > annexations, etc. However, OSM's community, through exhaustive consensus > (much of it right here on talk-us, many of these discussions are ref'd in a > wiki I noted earlier) agree that what the US Census Bureau says is not > necessarily what OSM does or should use to document such entities. In other > words, the Census Bureau is not authoritative. For what we agree to put into > OSM, the OSM community's consensus IS authoritative. We have agreed that > census boundaries of CDPs are statistical, not administrative (what > admin_level attempts to denote). We correctly document how to do this. > However, MUCH old TIGER data remain. > > Martijn, your OT link is helpful, here is a visual version: > http://overpass-turbo.eu/s/DG5 (although that does not allow "census.gov" to > appear as often as your text-based version does, so thank you for that > formatting). What this shows is that the importation of much Census Bureau > data as CDPs in Utah (and elsewhere in the USA) continues to have MUCH work > to do: our wiki suggests admin_level=8 tag be removed from these, and the > boundary=administrative tag be changed to boundary=census. This is correct, > it has achieved wide consensus in OSM (via these talk-us pages) and has been > documented in our wiki for some time. And not simply in Utah, this is true > in all 50 states, except Alaska, where the state works closely with the > Census Bureau to "organize" (not in the legal sense) the Unorganized Borough > of Alaska (bigger than any other state, even Texas). Carl offers a clever > way for us to sharpen up how we might do this: choose admin_level=8 tagged > relations which have tiger:LSAD=57 (e.g. Mona, Utah), change > boundary=administrative to boundary=census, and delete the admin_level=8 tag. > Import script, anyone? (Whew, that's a loaded question!) > > However, I disagree with Martijn (or perhaps I do not understand his > intention) as he says about our US_admin_level wiki > "United_States_admin_level is really not correct... CDPs should be tagged > boundary=census, ideally without an admin_level=* tag." I believe that IS a > correct statement, it is simply that Utah (and many other states, again, not > Alaska) have never had this "clean up" done. > > Martijn's assertion that "state municipalities: cities, towns, villages and > hamlets (infrequent)” is an incorrect description of what we INTEND to denote > with admin_level=8 in the USA is also incorrect. Simply said, hoary old > TIGER data contradicts this true statement on a fairly large scale, in Utah, > yes, but in most other states, too. > > Let's not confuse what's in the map (from a noisy TIGER import) as correct, > when what really is correct is what we have achieved consensus about and > wiki-documented: CDP data are boundary=census, not boundary=administrative > (and so, should have NO admin_level key, with any value). > > And, I'd much rather have "too much" wiki than "not enough." Wiki can be > ignored if too verbose, however, the consensus such wiki express is not > easily conjured. > > Where I agree with Martijn is "I guess we have some work to do." "Clean the > catbox" indeed! > > SteveA > California _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
