[Talk-us] TIGER 2022 PLACE dataset

[Minh Nguyen]

Vào lúc 09:02 2023-01-20, Brian M. Sperlongano đã viết:
> 
> 
> On Fri, Jan 20, 2023 at 11:54 AM Zeke Farwell 
> <ezekielf at gmail.com 
> <mailto:ezekielf at gmail.com>> wrote:
> 
>     On Fri, Jan 20, 2023 at 11:38 AM Brian M. Sperlongano
>     <zelonewolf at gmail.com
>     <mailto:zelonewolf at gmail.com>> wrote:
> 
>         if someone wants to know how many streets they've run in
>         Ellicott City, Maryland, I can't do that with an administrative
>         boundary, because Ellicott City is just an unincorporated part
>         of Howard County (despite being the county seat and having a
>         decently sized population). For Maryland, I use a select list of
>         census boundaries that serve as de-facto city boundaries for
>         handling the "in a city" problem for areas that aren't in an
>         incorporated city boundary but are otherwise locally understood
>         as a geographical place with extents.
> 
> 
>     Ok, that makes sense.  Is it important that the tag you're consuming
>     to obtain this area is boundary=census, or would an area tagged
>     place=city|town|village work just as well?
> 
> 
> In my particular case, it doesn't matter what it's tagged as long as 
> overpass treats it as an area -- and I'm not clear on whether overpass 
> handles all boundary/multipolygon relations as areas or if it's 
> tag-selective.  But nominally, the specific tag nomenclature isn't 
> important to me as long as I can query against it.

The Overpass API generates areas for all named type=boundary relations, 
among other things. [1]

>        What do you do when someone wants to run all the roads in Milton,
>     Vermont given Milton is mapped both as this admin boundary
>     <https://www.openstreetmap.org/relation/8897021> and as this census
>     boundary <https://www.openstreetmap.org/relation/199120>?
> 
> 
> I import all admin_level 7 and 8 boundaries by default and only add 
> other types of boundaries (such as census boundaries where needed) by 
> exception based on what makes sense in a particular area.  So in the 
> Vermont case, the census boundary simply wouldn't be in my database.  
> But this is just my particular use case and I can't speak to any other 
> data consumers.

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.

However, nothing currently stops a mapper from deleting a CDP boundary 
as cruft. (This has been the case for years.) 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.

[1] 
<https://github.com/drolbr/Overpass-API/blob/af71d8c8d17360a3b2956cf12edf463d6167fc0d/src/rules/areas.osm3s#L9-L12>

-- 
minh at nguyen.cincinnati.oh.us