[Talk-us] TIGER 2022 PLACE dataset

[Brian M. Sperlongano]

On Fri, Jan 20, 2023 at 2:46 PM Minh Nguyen <minh at nguyen.cincinnati.oh.us>
wrote:

>
> CDP geometries are clearly useful to StreetFerret as a backstop for
> named, populated, but unincorporated areas. It probably works OK in use
> cases where the user doesn't expect the precise geometry to be
> particularly meaningful.
>

Yes exactly.  Boundary accuracy is not terribly important for the use case
of gamifying exercise :)


> However, nothing currently stops a mapper from deleting a CDP boundary
> as cruft. (This has been the case for years.)


If a boundary gets deleted, then I drop it from my database.  I treat OSM
in essence as a foreign key and periodically poll for changes. If a
boundary changes, I reprocess data in that area.


> Would it be feasible for
> StreetFerret to join OSM data to the Census Bureau's CDP shapefile for
> the same information, but better? Unlike with administrative boundaries
> in general, mappers can't improve upon any CDP boundaries compared to
> what the Census Bureau publishes without departing from fact.
>

If there is both an administrative boundary and a census boundary in the
same area, I always prefer the administrative boundary.  The CDP is, as you
noted, a backstop. Trying to conflate CDPs with OSM data frankly isn't
something I would bother to do from a cost/benefit standpoint. My stance
has been "StreetFerret only supports boundaries mapped in OSM as areas". If
I were a company with more substantial resources, that might be worth
doing, but as a hobbyist cobbling together a service, sole-sourcing OSM
gets me to "good enough in nearly all cases".  Federating out to an
external data source for corner cases in a single country isn't worth the
time of code a new data pipeline to handle it. So if we decided to drop
CDPs from the map, then StreetFerret would simply no longer support those
areas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20230120/4429fc84/attachment-0001.htm>