<div dir="ltr">Weighing in late here:  I'm also against any sort of wholesale use of TIGER 2022 Places in my area.<div><br></div><div>I plead guilty to having used the CDP boundaries - generally as a last resort  when I don't have anything better.<br><br>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).  </div><div><br></div><div>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.)</div><div><br></div><div>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.  </div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>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.<br><br>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.  </div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 17, 2023 at 1:10 PM stevea <<a href="mailto:steveaOSM@softworkers.com">steveaOSM@softworkers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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).<br>
<br>
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.<br>
_______________________________________________<br>
Talk-us mailing list<br>
<a href="mailto:Talk-us@openstreetmap.org" target="_blank">Talk-us@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-us" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-us</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">73 de ke9tv/2, Kevin</div>