Brian Stromberg <brian.stromb...@gmail.com> writes: > As someone who does research with Census data, it would be helpful to keep > all Census geographies in place (at least until Census decides to get rid of > them). Someone will use them at some point. Additionally, they're an official > component of Census geographies, as bureaucratic as that might be. That alone > seems to make them significant enough to keep. Deleting them because they > appear useless seems short sighted. It's not like roads are deleted from OSM > just because nobody uses them.
Brian, Wolfgang, Clifford, Michael, talk-us: Census boundaries were imported, then, after these data were already in our map, consensus was reached that these were statistical areas, not administrative areas of government. Specific consensus was reached (in talk-us, if I recall correctly) on the following: • admin_level=8 was simply incorrect and should be deleted as a tag on these imported census boundaries, • boundary=administrative was also incorrect in all cases and should be changed to boundary=census as a tag on these. It is also specifically noted in our wiki[1] that in Alaska, as these boundaries were achieved with the cooperation of the Alaska state government in addition to the US (federal) Census Bureau, census boundaries in Alaska's Unorganized Borough are believed to be useful enough to keep in OSM, but, again, specifically without any admin_level tag, as (to repeat), census areas are not administrative boundaries. This consensus has resulted in most (all?) of these admin_level=8 tags (some were 7, likely from subsequent edits) being (correctly) removed and the boundary=administrative tag being (correctly) changed to a boundary=census tag, though this work to correct these Census Bureau import data may not be complete. The result is that what data do remain in OSM (what Brian says would be helpful to keep in place) are of marginal value (except in Alaska and perhaps a very few other places). If/as Brian finds these data useful, I caution him to keep all of this in mind and perhaps find another methodology to "do research" with these data of questionable value than by using them as they presently exist in OSM. I politely disagree with him that "someone will use (these data) at some point," for several reasons: the data age and are not updated, they do not "map" (in a language or mathematical sense) well onto specifically-rendered entities in any OSM renderer I know of, and (imo, I could be wrong) they only serve to add some sense of accuracy to perhaps geocoding or place-name lookups in what amounts to "hacked" corner cases. OSM can do much better here and indeed should do so without these census data in OSM whatsoever. So, except for in Alaska, census boundaries in OSM appear to have marginal or even no value to any present or future conceivable use case. While deleting them (except in Alaska) or "converting them to place=* nodes" may be the eventually correct solution(s), no organized effort to do so, or examination of the history or use-case-based arguments to keep them has emerged or presently exists. (We do document the situation in our wikis, footnoted below). I would like to see either the deletion of boundary=census entities entirely (except in Alaska) after a more-complete discussion of why and how they are presently used (perhaps in geocoding algorithms) and how better tagging on "more real" and/or "more stable" objects can and should supersede them. Virtually always (if not always), a node with tag place= with a consensus-sane value[2] completely suffices. Such cleanup (garbage-y, rapidly obsoleted polygons become a node) is very much in OSM's interest. Complicating this is the major issue of Indian Reservation boundaries. What has emerged as a stopgap[3] is to tag these with either boundary=aboriginal_lands or boundary=protected_area + protect_class=24, omitting the admin_level=* tag in either case. Please read our wiki as footnoted here, as this may suffice to persuade you to remove the Satus census object, replacing it with a node tagged place=* with little or no affront to your sense of correctness within OSM. These issues may seem complicated, though I posit that it is their history clouded by misunderstanding and poor introduction of US Census Bureau data into OSM that are to blame. This makes the bottom line straightforward: US Census Bureau census boundary data as polygons do not belong in OSM (except in Alaska, where they remain distinctly useful), since a node with a place=* tag delivers OSM's proper mapping of these semantics. SteveA California Contributor to our https://wiki.osm.org/wiki/United_States_admin_level and https://wiki.osm.org/wiki/WikiProject_United_States/Boundaries wikis OSM Volunteer since 2009, frequently in listening mode even as I offer what is hopefully august opinion [1] https://wiki.osm.org/wiki/United_States_admin_level#cite_note-8 [2] https://wiki.osm.org/wiki/United_States_admin_level#Unincorporated_areas [3] https://wiki.osm.org/wiki/United_States_admin_level#Native_American_reservations _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
