[Talk-us] TIGER 2022 PLACE dataset

[Kevin Kenny]

Weighing in late here:  I'm also against any sort of wholesale use of TIGER
2022 Places in my area.

I plead guilty to having used the CDP boundaries - generally as a last
resort  when I don't have anything better.

New York's structure of civil subdivision is complex:  we have Counties,
Cities, Boroughs, Towns and Villages; plus Hamlets (which do not have home
rule).

Since Hamlets don't have their own government, the taxing authorities
generally do not keep track of their boundaries. (I treat the Department of
Taxation and Finance as being very nearly the ultimate authority on the
political boundaries. It has the greatest financial interest in getting
them right.)

Nevertheless, some Towns (New York's counterpart to what many other states
call 'townships') do have defined boundaries for their Hamlets, and even in
some cases sign the names. They are often written into local law so that
things like parking and zoning regulations can simply name a community
rather than having to repeat the boundaries in each regulation adopted.
Often, these are defined as 'negative space' and most of their boundaries
will be the boundaries of the Town, a shoreline, or the boundary of an
adjoining Village.  Many of these are significant communities. The largest,
Brentwood, is a small city of some sixty thousand inhabitants.

The Census Bureau draws its CDP lines in consultation with the local civil
authorities, who generally need Census statistics for their respective
jurisdictions, including the unincorporated Hamlets. I know this to be true
in Nassau and Suffolk Counties, and suspect it in several others. Getting
the boundaries of unincorporated Hamlets can otherwise be tricky.  They can
sometimes be obtained from Town planning boards, or God help us, the
establishing legislations. Alternatively, sometimes County tax rolls show
them.  (But in many Counties the tax maps are copyrighted, have
incompatible licensing, and can't be imported to OSM lawfully.)

Where I have better information, I use it.  I find that TIGER Places (and
the corresponding information from the Census Bureau's web site and the
National Map) is wildly inaccurate even for the defined political
boundaries.  In no case have I wound up importing a CDP as a Hamlet without
at least conforming its boundaries to whatever lies beyond.

A big fraction of my OSM work in the past year was devoted to cleaning up
an inconsistent mess of New York county and municipal boundaries that came
into OSM as a result of several failed imports of the TIGER data.  I
haven't been around here that much lately, simply because I was a little
burnt out by the effort.  The necessary sleuthing for whether Hamlet
boundaries were statistical conveniences for the Census or actual
communities with defined bounds and local identities was beyond me for
areas where I don't have boots on the ground.  I did, of course, eliminate
the ones that were obviously just statistical, for example, where the CDP
boundary was nearly coterminous with a university campus, or where the name
obviously references two or more Hamlets.

There were also cases that left me at a loss - for instance, CDP's
following the boundaries of Villages that have voted to dissolve their
local governments and rejoin their containing Towns.

In borderline cases (pun intended, I suppose) I decided to leave the
`boundary=administrative` tagging in place.  I figured that it's more
likely that a local will see a boundary that should be demoted, and fix it,
then that the same mapper will find a `boundary-census` and upgrade it. In
fact, in doing the cleanup, I found several cases where a
`boundary=administratve` had been hand-mapped, ignoring a coincident census
boundary that was already there. (Most of these cases appeared to have
originated from mappers who didn't understand boundary relations; the
borders failed to close or had other inconsistencies that made them
useless.)

In any case, all the boundaries are tagged with FIPS code, GNIS feature ID,
Wikidata, and SWIS (New York's State-Wide Information System) identifier,
so update and repair should be easier in the future.

I vehemently oppose any sort of bulk import of the TIGER Place data.  I
also don't see a compelling reason to bring New York up to TIGER 2022.  I
understand that the CDP's will be the same, since they change only with the
decennial census. The boundaries of counties and of incorporated
municipalities have already been conflated with data sources that I think
are considerably more reliable, so any corrections that TIGER has for them
are likely already in OSM.

On Tue, Jan 17, 2023 at 1:10 PM stevea <steveaOSM at softworkers.com> wrote:

> To answer the very narrow sliver of question about this large topic
> regarding mapping census boundaries, I’ll offer this, which repeats much
> existing OSM history (and community dialog and eventually consensus, much
> of which was via mail-list discussion, the “tech of the time”) and
> wiki-documentation of that history.
>
> OSM does in fact map census boundaries, or better-stated, HAS mapped
> these, using a polygon tagged boundary=census.  OSM in the USA had a
> “collision” with boundary=admin_level (sometimes with an incorrect
> associated tag of admin_level=7 or 8), and not only have we reached
> consensus that NO admin_level tag should be associated with these, but that
> “census boundaries are not administrative boundaries” (the collision).
> Moreover, census boundaries are rather fluid, changing often enough that
> keeping them current would prove challenging over the breadth of an entire
> country, even with a growing number of Contributors in the USA.
>
> There are places where boundary=census polygons are quite significant,
> like in Alaska where in its Unorganized Borough (larger than any of the
> other 49 states), census boundaries are mutually agreed to between the
> (federal) Census Bureau and the state of Alaska.  And in some other cases,
> these might be “somewhat useful” (to OSM) geographical data in other parts
> of the USA, knowing that these data may change (especially after each
> decennial census).
>
> Broadening out to the greater topic of the whole of TIGER (2022, newer,
> PLACE dataset, or other datasets) data coming into OSM, it is
> well-established that (as other posters have well-noted), some sort of
> on-the-ground verification / validation of said data is crucially
> important.  A wholesale import of these data, even small-scale curation of
> selected parts of them, is unwarranted and perhaps even harmful to OSM — at
> least without fairly strict quality control measures (like concimitant
> “on-the-ground” knowledge to verify them).
>
> Importantly (about any external-to-OSM dataset, not just Census Bureau
> data):  simply because an external dataset exists does not mean it should
> be in OSM.  It may very well be that if a use case would be best served by
> 2022 PLACE data (for example), the best way to produce a solution is to use
> the data directly, not from within OSM because they’ve been imported or
> curated into OSM.
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20230120/6343e469/attachment.htm>