[Talk-us] TIGER 2022 PLACE dataset

[stevea]

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.