To-Add list of geodata

[nmpeterson]

Add the following geographic boundaries to the package, using scripts in data-raw that create .rda files in data.

• [x] CMAP Metropolitan Planning Area -- CMAP Data Hub
• [x] Counties (Modeling area plus MSA, combined) -- tigris
• [x] Municipalities (CMAP region) -- tigris
• [x] Chicago community areas (CCAs) -- Chicago Data Portal
• [x] Chicago wards -- Chicago Data Portal
• [x] Census tracts (CMAP region) -- tigris
• [x] Census block groups (CMAP region) -- tigris
• [x] Census blocks (CMAP region) -- tigris
• [x] Census public use microdata areas (PUMAs) (CMAP region) -- tigris
• [x] CMAP travel modeling zones -- CMAP Data Hub
• [x] CMAP travel modeling subzones -- CMAP Data Hub
• [x] CMAP subregional Councils of Mayors (COMs) -- CMAP Data Hub
• [x] Legislative districts (state and federal. Whole state with cmap flag.) -- tigris
• [x] Townships (political) -- tigris
• [x] IDOT districts (whole state) -- tigris (counties, dissolved by district ID)
• [x] Facility Planning Areas -- CMAP Data Hub
• [x] EDAs -- CMAP Data Hub (for now)

---

Also for consideration:

• [ ] PLSS Townships / Sections -- ISGS

[dlcomeaux]

IDOT regions would make sense as a county attribute, I don't think that needs to be its own shapefile if it's captured like that.

[dlcomeaux]

A few thoughts:

• The CMAP 7 counties + township nubs seems like it is going to have to be its own thing (since as you pointed out, it's not a subset of any county dataset, and thus won't be easily matched with county-level data).
• On a purely counties set, I guess I view all three of the ones you listed as valuable. Would it be too much to have each of them as an option - perhaps with the CMAP seven-counties as the default for "counties" but then counties_msa and counties_modeling as supplements?
• For Census tracts/block groups/blocks, I see the main value of this being that we are giving users an easily accessible tract/block level set of shapes that are in the CMAP region. More sophisticated users will likely have the capacity to extract tracts from a larger area, so I think within the CMAP region is probably the most appropriate. Same on PUMAs.
• For similar reasons, I would suggest that legislative districts only be those that overlap the CMAP region (although if that is too much trouble, the whole state seems like it would be fine too - perhaps with a flag for CMAP region inclusion in that case).
• Townships are occasionally useful to have. If it's not too much trouble, I'd say to include them.

[dlcomeaux]

And if we do include larger lists of tracts/block groups/PUMAs, I would definitely advocate for including a flag for CMAP region - otherwise, I think we lose the value of those shapefiles.

[nmpeterson]

@dlcomeaux yes, adding a CMAP region flag was always my intention for any dataset extending beyond the region, similar to what's already in zone_sf and subzone_sf. Regarding the townships, I assume you're referring to the political townships and not the PLSS townships?

[dlcomeaux]

@nmpeterson yes, the political townships - this came up for me on an analysis of infrastructure investment distribution. It's a less common need, but it does serve some purpose (particularly since they control some roadways).

[matthewstern]

I really liked the way you did the county vectors as differentiated objects that can be easily accessed as a whole list as well. Have you thought about whether it would be feasible to do something similar with geographies, that would allow the user to define what selection they wanted?

Seems like one option would be to include super basic helper functions that filter internal datasets, e.g. tracts("cmap"), tracts("modeling"), etc.

EDIT: Maybe I'm barking up entirely the wrong tree here, but theoretically, all the spatial data in the package could be internal and accessed via a function like cmap_spatial_data(dataset = "tracts", extent = "cmap7"), with convenience wrappers like tracts(extent = "cmap7"). This could allow the package to develop in the future into something more complex, e.g. something capable of not downloading all the data when you install the package, but caching data locally after it's called for once (I think tidycensus does something like this).

[nmpeterson]

Counties (modeling area + MSA combined) and IDOT districts (with IDOT region attribute) have been added.

@dlcomeaux does this format for the IDOT data work for you?

[dlcomeaux]

@nmpeterson yes that works great for what I was imagining. Thanks!

[nmpeterson]

Closing for now. Will reopen if there is demand for additional geographies.