[Talk-us] TIGER 2022 PLACE dataset

Thu Jan 19 01:01:40 UTC 2023

Oops, forgot to mention that yes, the CDP should never be
boundary=administrative. Use boundary=census. Those don’t show up on most
maps but can nonetheless be incorporated by any map/app using the
boundary=census data.

On Wed, Jan 18, 2023 at 7:55 PM Elliott Plack <elliott.plack at gmail.com>
wrote:

> Oh man, sorry I’m late to party here. CDPs are one of my favorite topics!
>
> First, from a DWG perspective (this paragraph only is me wearing the DWG
> hat), all data produced by the United States Census Bureau is public domain
> under United States law, and therefore is fully compatible with
> OpenStreetMap. Now, should you import it as polygons willy-nilly? No.
> Because most place data is already in the map and so to import it would
> mean conflating with existing data. You may update existing places with the
> latest census data, and overwrite boundaries that are there especially if
> they are from the original 2008 import. I have done this for many of the
> ones in Maryland. Whether you decide to conflate the boundaries with their
> roadway or river centerline data, using a multipolygon is up to you. As
> others have mentioned, these boundaries are not verifiable, and the census
> uses existing geographic features to delineate places where there is not a
> legal boundary, so I tend to reuse existing geometry in OSM, rather than
> create a duplicative feature.
>
> Now, my own perspective is that census designated places most certainly
> have a place in OpenStreetMap, because of complex rules about what defines
> a place in the United States. Some jurisdictions do not have any
> incorporated town boundaries and yet people refer to their area as a town.
> The CDP becomes the de facto boundary. One could argue that an incorporated
> town does not have any verifiable boundary either, (in an OSM perspective)
> as most town boundaries I’ve looked at are not painted on the ground, nor
> are there signs at every route crossing. While, it’s true that town
> boundaries may have a legal description, only United States federal
> documents are automatically public domain so local town incorporation
> documents may not be and often are not released in a public license. For
> that matter, what defines a state boundary? The United States has a
> standard geographic data set for state boundaries, but it can differ from
> what the states consider their own boundaries to be due to things like
> projections and surveying discrepancies.
>
> My point is that just because the CDP is not verifiable on the ground it
> does not mean that it should not be added to the map. Further, I think that
> all boundaries in OpenStreetMap transcend the rule about verifiability as
> there are many examples of boundaries between nation states that are not
> well defined nor are they agreed-upon, and yet we have to come to some
> semblance of an agreement about where those lines should be on our map.
>
> On Tue, Jan 17, 2023 at 7:39 PM MoiraPrime via Talk-us <
> talk-us at openstreetmap.org> wrote:
>
>> I will add my perspective here that in the past I've used TIGER PLACE
>> data to upgrade boundaries in Mississippi and add missing ones as well. The
>> original TIGER boundaries in OSM may be outdated, and they sometimes
>> improve them over time, so carefully looking and comparing them is
>> important.
>>
>> So I think if you're looking at a dataset and importing a TIGER PLACE
>> boundary, and you're doing them one by one as needed, that would be fine.
>>
>> To add a specific example, a couple months ago I imported the TIGER/Line
>> 2020 Place Shapefile for the city of Diamondhead, Mississippi (Relation:
>> ‪Diamondhead‬ (‪110003‬) | OpenStreetMap
>> <https://www.openstreetmap.org/relation/110003>). This is a city that is
>> fairly new. Previously it was simply a Census Designated Place, but about
>> 10 years ago the people there officially put in the effort to get it
>> established as a city government, and the City's boundary did not match
>> what the original CDP boundary was. In this case it was an improvement to
>> outdated data, and was personally checked by me and compared to the
>> previous data.
>> On 1/17/2023 10:01 AM, Bill Ricker wrote:
>>
>>
>>
>> On Tue, Jan 17, 2023 at 8:22 AM Aleksandar Matejevic (Hi-Tech Talents
>> LLC) via Talk-us <talk-us at openstreetmap.org> wrote:
>>
>>> I have a question regarding TIGER 2022 PLACE dataset (
>>> https://www2.census.gov/geo/tiger/TIGER2022/PLACE/).
>>> Is it OK with the community to add these polygons to the OSM?
>>>
>>
>> Can you point to the description of what these PLACE polygons represent
>> and what meta-data comes with each polygon?
>>
>> What are they in OSM terms? Are they Admin boundaries?
>>
>> (Do we even consider US Census CDP, Census Designated Place, a mappable
>> entity?)
>>
>> I saw there were some imports of the previous datasets in the past years,
>>> but lot of polygons are still missing,
>>>
>>
>> Can you provide (an) example(s) of what's missing from OSM but in TIGER
>> 2022 PLACE that would be beneficial in OSM?
>>
>> and license looks to be compatible with the OSM one.
>>>
>>
>> I expect so from history, but for the record of the conversation, it
>> would be good to link and quote it here.
>>
>>> I am not talking about mass import of the data,
>>>
>>
>> Ok good , that's a very different discussion.
>>
>>> but using polygons and adding them one by one if they are not already
>>> added and improving geometries of the existing ones.
>>> What is the opinion on this effort?
>>>
>>
>> Using individual polygons of compatible license to improve existing
>> polygons or to start a missing but useful polygon of a sort we are trying
>> to curate seems (almost*) unobjectionable.
>>
>> *Provided that there isn't a better source of compatible license easily
>> available for the polygon in question.
>> (E.g. if a specialist agency has lakes, forests that are more refined
>> than Census's, we'd prefer theirs.
>> US Census studies settlements for purposes of the enumeration -
>> notoriously did not record One Way direction as Enumerators walk their
>> blocks in cities - not uninhabited wildlands, so will likely have fewer
>> points in a polygon that indicates "no one lives here", while having
>> excellent polygons for "this is an incorporated place, inhabitant count
>> rolls-up to entity # NNNNN named YOUR PLACENAME HERE† at level LL" (we use
>> these as Admin boundaries?) and "this is an unincorporated place and the
>> census definition is this" (maybe we don't, as there's no Now Entering CDP
>> imaginary boundary signage?).)
>>
>> (OTOH if the better source is not easily available - or will require a
>> high level negotiation to get a compatible license statement from their
>> agency management!  - starting with the CENSUS polygon makes sense, even if
>> it's coarser than we'd ideally prefer.)
>>
>> † "Your State's Name Here <https://youtu.be/96Wtcpje0uE>" - Lou & Peter
>> Berryman - A Generic Folk-Song praising whatever state they're visiting and
>> performing in today.
>>
>> _______________________________________________
>> Talk-us mailing list
>> Talk-us at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
> --
> Sent from iPhone; kindly excuse tyops.
>
-- 
Sent from iPhone; kindly excuse tyops.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20230118/c847085b/attachment-0001.htm>