dfsnow / travel-time-matrices Goto Github PK

The input/ directory contains pre-calculated origins and destinations for 2010 Census tracts and ZCTAs. We should update it to include OD pairs based on 2020 Census geographies.

NOTE: The 2010 OD pairs are population-weighted centroids. These are calculated using the census block population counts available here. It seems like these block-level counts have not yet been released for 2020, so we may have to wait a bit.

Create a README file with:

• Dependencies and installation (osmium, R deps, curl)
• Basic workflow/usage
• Example input and output
• Caveats

Below is a plot of multi-model travel times in Cook County with the following settings:

Starting census tract = 17031031502
Departure time = 2021-04-16 20:21:17 CDT
Maximum walking distance = Infinite
Maximum trip duration = 600 minutes
Maximum number of rides = 5
Transit modes = TRANSIT (any mode) + WALKING
Destinations = All census tracts in Illinois ( + a 100 km buffer) reachable with 600 minutes
Walk speed = 3.6 km/h

The times and structure here look pretty reasonable to me. However, the sharp discontinuities (quick changes from purple/blue to yellow) really shouldn't be possible. I suspect they have something to do with the OSM network in the area, or maybe the walk speed is too low.

We should start to collect metadata on GTFS feeds (and corrective actions) used in this project in order to ensure reproducibility. Metadata can be stored in a simple flat file in inputs/shared/feeds and could contain fields such as date feed last updated (on TransitFeeds), feed location, feed name, list of potential errors/issues, and a list of corrective actions taken to fix said issues.

Potential feed issues include:

• Invalid geometries (usually incomplete linestrings). Can be corrected with any GIS geometry validator i.e. st_make_valid. OR dropping geometries, since they are not needed for r5r
• Invalid or unroutable route_type in feed. Can be fixed by forcing route_type to something within GTFS spec
• Arrival/departure times that are too fast or slow, resulting in bad travel times. Rafa suggests using gtfs2gps R package to correct times
• Missing information or files
• Scheduled dates outside of the dates needed for routing. Can be fixed by coercing dates into the desired routing date range

We may even want to compile a collection of validated feeds + metadata and tarball it in this repo. This would ensure reproducibility but would be a lot of work.

For feed validation, I've used this tool in the past. Google also has a tool here. Rafa also mentions they're working on a gtfstools R package specifically for this purpose.

Occasionally, r5r will generate a travel times matrix with an unroutable destination in the middle of an otherwise routable area. In the case of census tracts, this will appear as a grey (missing value) tract in the middle of an otherwise complete isochrone.

Destinations can be unroutable for a variety of reasons, including:

• Issues snapping the destination point to the OSM road network. Rafa's team discovered there is effectively a 1.6 km limit to the search space R5 will use for snapping. They are creating a PR to make this variable user-controlled.
• Road types? I'm not positive that this is true, but a cursory look at unroutable destinations made me think some of them landed on highways, which may not be walkable according to R5.
• Island road networks. I'm pretty sure R5 does things to clip/remove road network islands, but this was definitely an issue when using OTP.
• Bad centroids. Destinations are the centroids of polygons. However, not all census geometries are convex. You can find rare cases where concave geometries put your destination centroid in the middle of a lake. Population weighting your centroid (somewhat) fixes this issue, assuming there is a population to weight by.

We should investigate and try to fix each of these potential issues. However, my experience with OTP tells me that we'll likely always have some gaps in our output matrices. Rafa's team suggested taking an average of touching destination polygons to fill in gaps.