Re: [Talk-us] Satus CDP

[OSM Volunteer stevea]

Albert Pundt  writes
> 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. 

Thank you for your perspective Albert, and while you didn't ask a direct 
question, I am left with a couple myself after reading your observations:

Are these actually "towns" (or "cities") and so should be mapped 
boundary=administrative and admin_level=8?
Are these actually "suburbs" and so should be mapped as nodes tagged 
place=suburb inside of cities (which are mapped as the previous sentence)?

Noting in our United States admin_level wiki that a particular state SHOULD map 
with a particular "rungs on the ladder" hierarchy of particular admin_level 
values is useful, since by consensus we took our time to get those correct for 
that particular state.  THEN, there are assigning proper values on those proper 
entities, whether they came from the Census Bureau or need to be created/come 
from some other source.  If a census boundary exactly matches a city or town 
boundary, for example, (though it might prove challenging to discover or verify 
that), well, by all means:  rather than deleting that tagged polygon, we can 
simply change the tags from boundary=census to boundary=administrative, add an 
admin_level=8 tag (perhaps add a border_type=city tag) and be done until the 
next decennial census.

However, that's the tricky part: IS that Census Bureau-produced boundary truly 
the town or city boundary?  Or is it simply (and likely incorrectly) a "Census 
Bureau-produced boundary of census tract agglomerations" rather than a true 
corporate boundary as denoted by the city itself (or its parent state)?  Either 
might be correct, but as of now, data in our map are not sure.  In OSM, I'd 
like the data surely to be what it claims to be.  I don't believe we have that 
today with many Census Bureau boundaries, except that they denote a "boundary" 
of some sort:  sometimes correctly denoted "census" with no admin_level value 
(but should have one on a different and correct polygon), sometimes incorrectly 
denoted "administrative" with a questionable (maybe correct, maybe not) value, 
but on a polygon which is Census Bureau produced and possibly incorrect, 
possibly correct but we don't know that the Census Bureau exactly mapped a 
corporate boundary 

Locally speaking, they might appear to be "better than nothing, at least until 
the next decennial census," but ask yourself:  what are these really denoting?  
If the answer is "we don't know if this is a corporate boundary or not" then we 
must at a minimum change the boundary tag from administrative to census, 
deleting any admin_level tag.  (Taking note amongst ourselves that these 
boundaries are marginally useful at best, especially when there are entities 
like towns and cities that deserve to have their corporate boundaries in our 
map).

We've already achieved consensus that "CDPs are lesser entities."  I'm 
suggesting we go ahead and delete them as noise (except in truly useful 
circumstances absent any "better" data, as in Alaska).  Superseding them with 
better data:  I'm all for that where we can do so.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Satus CDP

[Albert Pundt]

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 
wrote:

> Brian Stromberg  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 

Re: [Talk-us] Satus CDP

[OSM Volunteer stevea]

Brian Stromberg  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] 

Re: [Talk-us] Satus CDP

[Michael Patrick]

>   1. Satus CDP (Clifford Snow)

In the middle of the Yakama Nation Indian Reservation sits Satus [1] that
as far as I know only exists in some Census bureaucrat world. Asking around
here I haven't found anyone familiar with the area. Wikipedia [2] doesn't
help much either.

I'd like to remove it from OSM. What reasonable checks do I need to do
before> deleting it.

The Yakima Tribe has a GIS Department
, also Yakima County
 - I'd pop them a note.

Also the Tribal Cultural Center .
>From the WA State metadata, Satus falls in the contested treaty lands zone.
Under various legal and administration perspectives, BIA reservation
boundaries are not the last word. There are many situations where tribes
have influence over areas outside reservation boundaries. It might even
spur them and their members to contribute to the map.

Inversely, it might have been dropped from the Census on their request -
some place names have a negative historical narrative.

Having the US Census import as the origin of much map creates these
situations - a place name may be hugely important to the local community,
for instance, because it is a cross roads, or has some sort of other
centrality, but appears to have nothing 'on the ground'. The main goal of
the census was statistical areas, since the roads are readily available
'boundary' they are their, but their actual spatial accuracy is irrelevant
to some extent - but topology was critical. .

i.e. "ask the locals" :-)

   - *Mission Statement: Provide the Nation with relevant and reliable
   geographic and parcel information for all lands of tribal interest. This
   information supports tribal resource specialists in creating innovative
   management solutions while protecting the rights guaranteed the Yakama
   Nation by the Treaty of June 9, 1855. (509) 865-5121 Ext. 4647*

Michael Patrick
Data Ferret





Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Satus CDP

[Brian Stromberg]

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

On Feb 27, 2018 2:30 AM, "Wolfgang Zenker" 
wrote:

* Clifford Snow  [180227 01:59]:
> In the middle of the Yakama Nation Indian Reservation sits Satus [1] that
> as far as I know only exists in some Census bureaucrat world. Asking
around
> here I haven't found anyone familiar with the area. Wikipedia [2] doesn't
> help much either.

> I'd like to remove it from OSM. What reasonable checks do I need to do
> before deleting it. Or do they belong in OSM and I should leave it alone.

> I should add that the reason I want to delete it is because currently
> shares a boundary with the Yakama Nation. The boundary needs updating.

I would delete it, the boundary is useless. The name is still on the
place node next to what I guess used to be the railway station.

Wolfgang
(lyx @ osm)

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

Re: [Talk-us] Satus CDP

[Wolfgang Zenker]

* Clifford Snow  [180227 01:59]:
> In the middle of the Yakama Nation Indian Reservation sits Satus [1] that
> as far as I know only exists in some Census bureaucrat world. Asking around
> here I haven't found anyone familiar with the area. Wikipedia [2] doesn't
> help much either.

> I'd like to remove it from OSM. What reasonable checks do I need to do
> before deleting it. Or do they belong in OSM and I should leave it alone.

> I should add that the reason I want to delete it is because currently
> shares a boundary with the Yakama Nation. The boundary needs updating.

I would delete it, the boundary is useless. The name is still on the
place node next to what I guess used to be the railway station.

Wolfgang
(lyx @ osm)

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

Re: [Talk-us] Satus CDP

[Paul Norman]

On 2/26/2018 4:59 PM, Clifford Snow wrote:
In the middle of the Yakama Nation Indian Reservation sits Satus [1] 
that as far as I know only exists in some Census bureaucrat world. 
Asking around here I haven't found anyone familiar with the area. 
Wikipedia [2] doesn't help much either.


I'd like to remove it from OSM. What reasonable checks do I need to do 
before deleting it.


It sounds like you've done them.


Or do they belong in OSM and I should leave it alone.


CDPs don't belong in OSM for their own sake.* In some cases, a CDP 
corresponds to a real place, and they're useful then. In other cases, 
they have no relation to the situation on the ground, and shouldn't be 
in OSM.


* Leaving aside Alaska, which has an administrative structure different 
than the rest of the US.


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

Re: [Talk-us] Satus CDP

[Mark Wagner]

Satus has a population of 750 people scattered across 70 square miles
of farmland.  The largest population center I've been able to find from
aerial imagery has ten buildings, three of which look rather abandoned
in Google Street View.

Looking through Google Books results, it definitely *was* a community:
I'm seeing references from the 1910s to the 1940s.  After 1945, though,
the search results are either for the CDP or are Satus mailing
addresses.

As far as I can tell, it's not an unincorporated community in the way
that someplace like Anatone[1] is, or a recognized region such as
Mead[2].  The Satus CDP appears to simply be a bookkeeping region
for the census that was given an old name.  I'd have no trouble calling
it a "place=locality", but calling it any sort of "significant
community" seems like an exaggeration.

[1]: https://en.wikipedia.org/wiki/Anatone,_Washington
[2]: https://en.wikipedia.org/wiki/Mead,_Washington

-- 
Mark

On Mon, 26 Feb 2018 20:27:45 -0600
Chris VandeVenter  wrote:

> I would leave it in place.  Census designated place is a place that
> is not incorporated as a city  under state law but is still a
> significant community. It’s been a large debate on Wikipedia about
> their, but general consensus is they are significant enough to
> include. The CDP boundary follows what the community would have if it
> were an incorporated city. For example, U.S. Air Force bases are
> generally treated as census designated places. 
> 
> Chris VandeVenter
> Sent from my iPhone
> 
> > On Feb 26, 2018, at 6:59 PM, Clifford Snow
> >  wrote:
> > 
> > In the middle of the Yakama Nation Indian Reservation sits Satus
> > [1] that as far as I know only exists in some Census bureaucrat
> > world. Asking around here I haven't found anyone familiar with the
> > area. Wikipedia [2] doesn't help much either.
> > 
> > I'd like to remove it from OSM. What reasonable checks do I need to
> > do before deleting it. Or do they belong in OSM and I should leave
> > it alone. 
> > 
> > I should add that the reason I want to delete it is because
> > currently shares a boundary with the Yakama Nation. The boundary
> > needs updating.
> > 
> > 
> > [1]
> > https://www.openstreetmap.org/relation/237292#map=11/46.2322/-120.1180
> > [2]
> > https://en.wikipedia.org/wiki/en:Satus,%20Washington?uselang=en-US
> > 
> > Thanks,
> > Clifford
> > 
> > -- 
> > @osm_seattle
> > osm_seattle.snowandsnow.us
> > OpenStreetMap: Maps with a human touch
> > ___
> > Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us  


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