Add basic spatial visualization

[shankari]

• Start/end points
• Heatmap
• Trajectory mapping
• Pixel-specific ratios

Most of these analyses were generated for Denver as part of the exploration of MEP integration The trajectory mapping was initially generated for Durham

The notebook relies on two sets of shapefiles:

• Denver boundary
• Denver boundary, gridded into 100m pixels

Both of these are courtesy the MEP team

Note that the notebook currently takes several hours to run. The majority of this time is spent in the trajectory mapping, which takes ~ 5 hours on my very powerful laptop.

[shankari]

Expected Results:

Trip O-D points (blue: all, green: e-bike, red: car-like):

O-D points (folium):

geopandas heatmap:

seaborn kde plot:

[shankari]

Denver e-bike trajectories:

[shankari]

Pixels where e-bikes were used more than cars:

Smart commute O-D distribution

Prepilot O-D distribution

ebike > car pixels for smart commute

pixel stats for smart commute

ebike > car for prepilot

pixel stats for prepilot

For completeness, other programs (not smart commute or prepilot) O-D

For completeness, other programs (not smart commute or prepilot) ebike > car

other program O-D further split by mode ()

for the cross-border travel, note that:

• shared ride is used way more often than drove alone, for most programs, Denver is quite far, so it makes sense to carpool
• except for cc, which was based in boulder, so maybe close enough to drive alone for errands etc
• e-bike is concentrated near the boulder border, and in downtown
• Downtown use is presumably in conjunction with transit - you should be able to validate against trip labels
• At TRB, there was some argument that e-bikes won't help with climate change because most of the emissions are from suburban travel into cities. this might provide some very high-level discussion on how much cross-border travel there is and how much e-bikes can help and how much would need pairing with better medium-distance transit options)
• e.g. by looking at trip purpose and time of day for the cross-border trips, maybe the model of morning express buses to downtown and evening express buses to the suburbs doesn't meet current travel demand

[shankari]

For the record, this is the cross-border travel O-D, color coded by program, but I think that the last figure in the previous comment is much clearer

[shankari]

@swasti10, can you generalize this and integrate it into the automatically computed public dashboard?
As you know, the steps for this involve using the ipynb file here to generate figures that we display in the static webserver.

• add to set of commands on docker that display figures in static webserver
• this is currently hardcoded for Denver and has the Denver boundary and a set of 1kmx1km pixels within the Denver boundary as the inputs
  • you need to generalize this so that the locations of boundary and the pixel shapefiles are in the dynamic config
  • Ideally, this config would be pulled directly from a public data source such as the Census Bureau, with proper attribution.
  • If this is not easy to automate, we can fall back to shapefiles on GitHub similar to the survey configs, and ask partners to specify them while signing the MOU.
  • I looked into the grid briefly, but I was not able to find a geopandas/shapely method to generate a 1km x 1km grid within a boundary. Cemal recently did this for a paper we are writing, so you could ask him how he did that but it may be using commercial software such as ArcGIS. If so, I could be fine with using census tract information, which is available from the census, instead for now.
• we probably want to hold off of the trajectories until we implement map matching, so that we don't overload the server
• we should only generate spatial values if there are at least 3 users in the database; we don't want to leak user-specific trip start/end locations by mistake which is what will happen if we have only one user in the database.