Loading Intermediate Data (largely automatically)#

To load intermediate data, use rt_filter_map_plot.from_gcs to create an RtFilterMapper instance for the itp_id and date of interest.

Filtering#

Using the set_filter method, RtFilterMapper supports filtering based on at least one of these attributes at a time:

Mapping, charting, and metric generation methods, listed under “dynamic tools” in the chart above, will respect the current filter. After generating your desired output, you can call set_filter again to set a new filter, or use reset_filter to remove the filter entirely. Then you can continue to analyze, without needing to create a new RtFilterMapper instance.

Mapping#

Use the segment_speed_map method to generate a speed map. Depending on parameters, the speeds visualized will either be the 20th percentile or average speeds for all trips in each segment matching the current filter, if any. See function docstring for additional information.

The map_variance method, currently under development, offers a spatial view of variation in speeds for all trips in each segment matching the current filter, if any. This is now quantified as the ratio between 80th percentile and 20th percentile speeds, and used on the CA Transit Speed Maps tool.

More performant maps via embedded app#

Rather than render the maps directly in the notebook via geopandas and folium, we now have the capability to save them as compressed GeoJSON to GCS and render them in an IFrame using a minimal web app.

This method is much more efficient, and we rely on it to maintain the quantity and quality of maps on the CA Transit Speed Maps site.

display_spa_map will always show the most recent map generated with either segment_speed_map or map_variance, then saved via map_gz_export.

stop_segment_speed_view#

After generating a speed map, the underlying data is available at RtFilterMapper.stop_segment_speed_view, a geodataframe. This data can be easily exported into a geoparquet, geojson, shapefile, or spreadsheet with the appropriate geopandas method.

*disaggregate value – applies to this trip only

**aggregated value – based on all trips in filter

Other Charts and Metrics#

The chart_variability method provides a descriptitive view of the speeds experienced by each trip in each segments. It requires that a filter first be set to only one shape_id.

The chart_speeds and chart_delays methods provide aggregate charts showing speed and delay patterns throughout the day.

The describe_slow_routes method lists out the routes in the current filter experiencing the lowest speeds. It is mainly used on the California Transit Speed Maps site.

Corridor Analysis#

It’s often useful to measure transit delay on a specific corridor to support technical metric generation for the Solutions for Congested Corridors Program, Local Partnership Program, and other analyses.

If you’ve received a corridor from an SCCP/LPP applicant or elsewhere, load it as a geodataframe and add it using the add_corridor method. If you’re already looking at a speed map and want to measure delay for a portion of the map, you can use the autocorridor method to specify a corridor using a shape_id and two stop_sequences. This saves time by avoiding the need to generate the polygon elsewhere.

The corridor must be a single polygon, and in order to generate metrics it must include at least one transit stop.

Once the corridor is attached, the quick_map_corridor method is available to generate an overview map of the corridor, including the transit stops just before, within, and just after the corridor. The corridor_metrics method will generate both a speed-based and schedule-based transit delay metric.

The speed-based metric is a daily average of the sum of delays for each trip traversing the corridor as compared to a reference speed of 16 miles per hour. To further explain, we take each corridor trip that we have data for and calculate the hypothetical time it would take for that trip to traverse the corridor at a speed of 16 mph. The difference between the actual time it took for the trip to traverse the corridor and that hypothetical time is the speed-based delay for that trip, and we sum those delays to create the metric. This metric is intended to provide a more consistent basis for comparison independent of scheduling practices.

In other words, if we expect a hypothetical bus lane/signal priority/payment system etc to increase corridor speeds to 16mph, this is how much time we could save per day.

The schedule-based metric is a daily average of the sum of median trip stop delays along the corridor. To further explain, we take each corridor trip that we have data for and look at the delay in comparison to the schedule at each stop, after subtracting off any delay present as the trip entered the corridor. For each trip we then take the median delay of all stops along the corridor, and sum these medians to create the metric.

Finally, you can use the corridor = True argument in the segment_speed_map method to generate a speed map for only corridor segments.

While all of these methods respect any filter you may have set with set_filter, don’t set a filter for SCCP/LPP metric generation.