[Talk-us] Satus CDP

Albert Pundt roadsguy99 at gmail.com
Wed Feb 28 23:29:49 UTC 2018

Many towns and suburbs in my area are only CDPs, and having proper
boundaries for them seems like it'd be useful, especially in more densely
populated  areas. It's not like there's any fuzziness with them either,
since they're defined by the Census Bureau and could only change once every
10 years. Only one U.S. census has occurred in OSM history, so it's not
like we'd be constantly updating them.

On Wed, Feb 28, 2018, 17:40 OSM Volunteer stevea <steveaOSM at softworkers.com>

> Brian Stromberg <brian.stromberg at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20180228/9bdbdfab/attachment.html>

More information about the Talk-us mailing list