pbpp-metrics-materials

Materials to support the calculation of some federally-mandated roadway performance metrics.

Contents

The contents of this repository:

• tmc-lists folder - contains list of all TMCs on the NPMRDS in the Boston Region MPO area in various forms:
  • npmrds_tmc_brmpo_nhs.csv - list of TMCs in CSV format
  • npmrds_tmc_brmpo_nhs_no_quotes.txt - comma-separated list of TMCs without quotes, for use when querying RITIS
  • npmrds_tmc_brmpo_nhs_with_quotes.txt - comma-separated list of TMCs with quotes, for use when performing database queries, e.g., with ArcGIS
• tmc-identification folder
  • TMC_Identification.csv - file obtained from RITIS when querying for the list of TMCs, above. Contains AADT data for each TMC.
• sample-data folder - contains data returned by RITIS when querying the list of TMCs above for data on June 15, 2022
  • brmpo_npmrds_15June2022-all-vehicles.csv - CSV file from querying for data for all vehicles
  • brmpo_npmrds_15June2022_trucks.csv - CSV file returned from querying for data for trucks only
• speed-limits folder
  • tmcs_with_speed_limit_from_cmp.csv - CSV file of {TMC, speed_limit} pairs for TMCs that were included in the last CMP
  • tmcs_with_speed_limit_from_cmp_no_quotes.csv - the above list of TMCs, comma-delimited without quotes
  • tmcs_with_speed_limit_from_cmp_with_quotes.csv - the above list of TMCs, comma-delimited with quotes
• shapefile folder
  • Massachusetts.zip - Compressed NPMRDS TMC shapefile for Massachusetts, downloaded from RITIS
  • Massachusetts.{dbf, prj, shp, shx} - Files extracted from the above ZIP archive
• massdot-materials folder
  • TMC-and-speed-events.gdb.zip - compressed file geodatabase containing:
    • Conflation_Vector - undocumented / unknown
    • LRS_Routes -'routes' event table / feature class, from the MassDOT Road Inventory
    • LRSE_Speed_Limit - 'speed limit' event table / feature class, from the MassDOT Road Inventory
    • LRSE_SpeedRegulation - 'speed regulation' event table / feature class, from the MassDOT Road Inventory
    • TMC_proposal - undocumented / unknown
    • TMC_not_null_weighted_SR.xlsx - table produced by 1spatial.com mapping TMC (here: Traffic_ID) to distance-weighed speed regulation
• results folder
  • npmrds_tmc_brmpo.csv - final results table, in CSV format
  • working3.gdb.7z - 7z-compressed file Geodatabase containing intermediate results of running Approach #2, below

Notes on the Contents of the massdot-materials folder

The TMC_not_null_weighted_SR.xlsx spreadsheet was shpped to RITIS by Charles Major of MassDOT on September 26, 2023, and shared with the author of this document by David Knudsen on November 22, 2023.

The compressed TMC-and-speed-events.gdb geodatabase was obtained from MassDOT and shared with the author of this document by David Knudsen on November 28, 2023.

Comments on the contents of this geodatabase from David Knudsen:

You must filter time-wise in the two speed event layers by deleting records where To_Date IS NOT NULL! The two layers are up-to-the-minute current. The LRSN_Routes layer is a couple months old: what I sent to 1Spatial to run their routines against. Their layer "TMC_PROPOSAL" dates to 2023-10-24, based on the 2021 TMCs, I think. I don't know much about what all of their fields mean.

Notes on Overall Methodology

The formula for calculating the Peak Hour Excessive Delay metrics, as defined by the FHWA is:

Peak Hour Excessive Delay - ALL PHED during 15-minute increments during peak hours (eventually converted to hours) Traffic congestion will be measured by the annual hours of peak hour excessive delay (PHED) per capita on the NHS. Excessive delay will be based on travel time at 20 miles per hour or 60 percent of the posted speed limit travel time, whichever is greater, during in 15-minute intervals per vehicle. https://www.fhwa.dot.gov/tpm/faq.cfm#phed

In order to calculate this metric, for each TMC included in the analysis, we will need:

1. travel time data
2. the 'posted speed limit'

Item (1) can be obtained directly from RITIS. Item (2) is a bit more of a challenge.
Even though MassDOT maintains posted speed limit data (and 'speed regulation') data in the Road Inventory, this data is stored in 'event tables' which are effectively overlayed on the underlying MassDOT route system. The challenge here is that the relevant event tables do not segment the underlying route system in the same way the TMC network does. In other words, the two systems, in general, don't 'line up.' This makes obtaining the actual speed limit for a TMC (as needed in these calculations) less than straightforward.

Of all the TMCs in the NPMRDS in the Boston MPO region, the majority - 2,767 - are part of the Congestion Management Process (\CMP) TMC network. This is very good news, because as part of the CMP, CTPS staff conflated the CMP-specific portion of the TMC network with the Road Inventory, and obtained the speed limit for each TMC. Athough much of this work was automated the final conflation required manual review and correction, particulary for TMCs that were not on express highways. For all the TMCs that are part of the CMP network, we will use the speed limit from the CMP as we have high confidence in its accuracy.

This leaves the question of how to obtain speed limits for the remaining 1,956 TMCs. The methodology we adopted relies upon the work of a consulting firm, 1spatial.com, that was hired by MassDOT to conflate the full INRIX TMCnetwork with the MassDOT Road Inventory a year or so ago. This conflation was performed completely programmatically;no review and correction by humans was invovled. As part of the conflation, 1spatial produced an event table / feature class of TMC IDs and the associated 'Weighted_Average_SR' - the distance-weighted speed_regulation for the TMC. (Note: 1spatial is headquartered in the UK, and its website is apparently hosted there. Due to geo-blocking on the CTPS firewall, the 1spatial.com website is not visible from within the CTPS network.)

While speed_regulation isn't identical to speed_limit, Bob Frey of MassDOT's Office of Transportation Planning has advised CTPS that it should be taken as more authoratative than speed_limit. Consequently, we will first attempt to use the speed_regulation value to come up with a 'speed limit' for the remaining TMCs.

Approach 1 - Harvest Data from the Speed_Regulation Event Table

This section documents the methodology for calculating the 'speed limit' for TMCs in the NPMRDS within the Boston Region MPO area but that are not included in the CMP __using data in the MassDOT Speed_Regulation Event Table. In point of fact, the process was run on all NPMRDS TMCs in the MPO region, but it was used to obtain the speed limit only for those TMCs that are not part of the CMP. As noted above, the reason for this is that the speed limits for TMCs included in the CMP were obtained as a result of a conflation between the TMC network and the Road Inventory that was partially automated, but also subject to review and correction by humans. The methodology described here relies upon a purely programmatic conflation (performed by 1spatial.com) that was not subjected to review and correction by humans; it is thus judged less reliable.

Approach 1 - Overview

The general approach taken begins by calcuating the intersection of 'TMC_Proposal' and 'LRSE_SpeedRegulation'. From the result of the intersection the speed limit that applies along each 'TMC part' is calculated, and finally the results from all the 'parts' comprising each TMC is aggregated. There is some hand-waving involved in this description; all the nitty-gritty details are described in the 'Detailed Steps' section, below.

TMC_Proposal is a feature class produced by 1spatial that indicates the 'from-measure' and 'to-measure' of each TMC with respect to each MassDOT RouteID with which it is associated. LRSE_SpeedRegulation is a feature class taken from the MassDOT Road Inventory that indicates the 'from-measure' and 'to-measure' along a given MassDOT Route_ID that a given speed regulation value applies.

The intersection is performed by the ESRI Overlay_Route_Events tool. This tool takes event tables, rather than feature classes as inputs. So, as a preparatory step each of the feature classes is exported to a 'vanilla' table in a Geodatabase.

The basic approach taken is to use the $D = R * T$ formula to calculate the speed limit for each TMC.

Approach 1 - Detailed Steps

1. Export the LRSE_SpeedRegulation feature class as a 'vanilla' table that will be used as an event table. The 'route identifier' field in this table is Route_ID; the 'from-measure field is From_Measure; the 'to-measure' field is To_Measure.

2. Export the TMC_Proposal feature class as a 'vanilla' table that will be used as an event table. The 'route identifier field in this table is PROPOSAL_LRS_ROUTE_ID; the 'from-measure' field is Begin_Measure; the 'to-measure' field is End_Measure.

3. Run the Overlay_Route_Events tool, saving the output to a table called TMC_SpeedReg_overlay_ETbl. The parameters to the tool invocation are as follows:

• Input event table: TMC_Proposal_ETbl
  • Route identifier field: ROPOSAL_LRS_ROUTE_ID
  • Event Type: LINE
  • From-measure field: Begin_Measure
  • To-measure field: To_Measure
• Overlay event table: LRSE_Speed_Regulation_ETbl
  • Route identifier field: Route_ID
  • Event type: LINE
  • From-measure field: From_Measure
  • To-measure field:: To_Measure
• Type of overlay: INTERSECT
• Overlay (output) event table: TMC_Speed_Reg_overlay_ETbl
  • Route identifier field: PROPOSAL_LRS_ROUTE_ID
  • Event type: LINE
  • From-Measure Field: Intersect_From
  • To-Measure Field: Intersect_To
  • Keep zero length line events: TRUE
  • Include all fields from input: TRUE
  • Build index: TRUE The result of this overlay operation is a table of 'TMC fragments'.

4. Select all records with a NULL or 0-value Speed (i.e., speed regulation) field in TMC_SpeedReg_overlay_ETbl, and delete them. NOTE: the 'Speed' field in this table is aliased to 'Speed_Limit', making it difficult to spot unless one has turned off 'Show Field Alias'.

5. The TMC_SpeedReg_overlay_ETbl contains one record for each 'TMC piece'. Add a new field, dist of type double to this table, and calculate its value as $abs(Intersect To - Intersect From)$. (We need to use the abs function here, because there are cases in which the From measure can be Less than the To measure in an event table.)

6. At this point, we have a speed value and a dist (distance) value for each 'TMC piece'. Given this, we can calcuate the travel_time for each 'TMC piece', using the $D = R * T$ formual. Add a field named travel_time, of type double to TMC_SpeedReg_overlay_ETbl. Calculate its value as $dist / speed$.

7. Calcualte the total length of each TMC, using the Summary Statistics tool. The parameters to the tool invocation are:

• Input table: TMC_SpeedReg_overlay_ETbl
• Output table: tmc_dist_Tbl
• Statistics field: dist
• Statistics type: SUM
• Case field: TMC
  The result of this operation is a table of { TMC, FREQUENCY, SUM_distance } triples. The FREQUENCY column can be ignored for our purposes.

8. Calculate the total travel time along the entire length of the TMC, using the Summary Statistics tool. The parameters to the tool invocation are:

• Input table: TMC_SpeedReg_overlay_ETbl
• Output table: tmc_travel_time_Tbl
• Statistics field: travel_time
• Statistics type: SUM
• Case field: TMC
  The result of this operation is a table of { TMC, FREQUENCY, SUM_travel_time } triples. Again, the FREQUENCY column can be ignored for our purposes.

9. Now that we have the total length and total travel time for each entire TMC, we can calculate the speed limit for each entire TMC using the $R = D / T$ formula. Join tmc_dist_Tbl and tmc_travel_time_Tbl on 'TMC', and export the result to tmc_speed_limit_Tbl.

10. Calculate a 'draft' speed limit for each TMC:

• Add a field speed_limit_draft, field of type double, to tmc_speed_limit_Tbl. Calculate its value as $SUM dist / SUM travel time$.

11. In general, the 'draft' speed limit values may not be integral; even if they are integers, they may not be multiples of 5 (as are speed limits). Add a new field, speed_limit, of type long to tmc_speed_limit_Tbl; cacluate its value to to $int(5 * round(draft speed limit / 5))$ to ensure that the resulting calculated speed limit is an integral multiple of 5. This gives a speed limit for all TMCs in Massachusetts, based on MassDOT's Speed_Regulation event table and 1spatial's conflation of the TMC network with the Road Inventory.

12. As noted above, as part of our work on the CMP we have speed limit data that has been subject to review and correction by a human for all TMCs in the CMP network. When we have a speed limit for a TMC from the CMP, we will use it in favor of the one calculated above. For all other TMCs, we will use the speed limit as calculated above. We accomplish this as follows:

• Join tmc_speed_limit_Tbl to cmp_2019_tmc_speed_limit on the 'TMC' field.
• Export the result to non_cmp_tmc_speed_limit_Tbl
• Select all records for which the speed_limit from the CMP speed limit table is NULL, and delete them.
• Prune this table by removing all fields except TMC and the speed_limit field that came from the joined table, and save the result in non_cmp_tmc_speed_limit_Tbl_pruned. The result is a table of speed limits for TMCs that are not part of the CMP network. Note that this includes TMCs that are outside of the Boston Region MPO area.

13. Merge the non_cmp_tmc_speed_limit_Tbl_pruned table and the cmp_2019_tmc_speed_limit table, producing the final_MA_tmc_speed_limit_Tbl. As the name of this file indicates, it includes TMCs throughout the sate, including those ouside the Boston MPO region.

When these TMCs were removed from the table, we found that it did not yeild speed limit data for any TMCs for which we didn't already have a speed limit from the CMP.

Approach 2 - Harvest Data from the Speed_Limit Event Table

The approach of harvesting speed limit data from the Speed_Regulation event table having borne no fruit, we turn now to harvesting this data from the Speed_Limit event table.

Although there are many more events in the Speed_Limit event table than in the Speed_Regulation event table, all of the data in it hasn't been vetted recently, and it is regarded as the less authoritative of the two. Nonetheless, it is the only alternative available.

Obtaining speed limit data from he Speed_Limit event table is much more difficult than obtaining it (if available) from the Speed_Regulation event table: the Speed\Limit table only carries speed limit data on the primary route; this is a challenge when two routes are concurrent - which is typically the case for non-limited-access roads. For example: Where Route 62 EB and Route 62 WB are concurrent, speed limit data is carried only in events on Route 62 EB (the primary route direction); speed limit data for the corresponding section of Route 62 WB is carried in the opposing_speed_limit event on Route 62 EB. This makes processing much more complicated.

Approach 2 - Detailed Steps

Inputs:

• MassDOT LRS_Routes feature class
• MassDOT Speed_Limit (LRSE_Speed_Limit) event feature class
• TMC_proposal feature class - this is the feature class produced by 1spatial conflating the INRIX TMC network with the MassDOT Road Inventory

1. 'Clean up' the LRSE_Speed_Limit FC. The approach here is to populate the Op_Dir_SL (opposing direction speed limit) with the value of the Speed_Lim (primary direction speed limit) field, whenever Op_Dir_SL contains no useful information. This is the case when its value is NULL, or 0, or 99.

• Select all records for which Op_Dir_SL is NULL, 0, or 99.
• From these, select all records for which Speed_Lim is NULL, 0, or 99, and delete them. These records have no speed limit data that can usefully participate in the following calculations.
• For the remaining records, set the Op_Dir_SL field to the value of the Speed_Lim field.
• Select all records for which the Op_Dir_SL field is still NULL, 0, or 99, and delete them. (These records had NULL, 0, or 99 values in their Speed_Lim field to begin with.)
• Delete all records from the Speed_Limit FC which have a shape_length of 0.
• Save the results of these 'cleanup' steps to a new feature class: LRSE_Speed_Limit_clean

2. Calculate the bearing of the geometry of each feature in the LRSE_Speed_Limit_clean FC. This is most efficiently performed by running the Add Geometry Attributes tool, specifying the LINE_BEARING parameter. This tool alters its input FC, writing the angular bearing (in degrees) to it in an attribute named BEARING. The tool offers no options to specify the name of this attribute; it is hard-wired to 'BEARING'. In a subsequent processing step (Step 8), we will calculate the bearing of the TMC features 'located' against the LRS_Route route system, we need to rename the BEARING field produced here to something else: LRSE_spd_lim_bearing.
   In summary:

• Calculate the bearing of the LRSE_Speed_Limit_clean FC using the Add Geometry Attributes tool.
• Rename this field to LRSE_spd_lim_bearing using the Alter Field tool.

3. (Preparation for Step 4.) Make a spatial selection on the LRS_Routes FC: select all features that CONTAIN the LRSE_Speed_Limit_clean FC. (David K. recommends using the CONTAINs selection criterion rather than INTERSECTs, as the latter can pick up 'touching' orthogonal routes that have nothing to do with the routes we want in the spatial overlay.) Save the selected features as the LRS_Routes_selected FC.

4. Spatially intersect the LRSE_Speed_Limit_clean FC and the LRS_Routes_selected FC (after Step 3. has been executed on it). Save the result in a new feature class called intersect_FC. (Here David K. suggests that some experimentation with the overlay tool may be needed: Intersection is similar to INNER JOIN, Identity to LEFT OUTER JOIN, and Union to FULL OUTER JOIN.)

5. Use the Locate Features Along Routes tool to locate intersect_FC on the LRS_Routes_selected route system feature class. The result is an event table we'll call located_features_ET. The parameters to the tool invocation are:

• Input Features: intersect_FC
• Input Route Features: LRS_Routes_selected
• Route Identifier Field: Route_ID
• Output Event Table: located_features_ET
• Output Event Table Properties:
  • Route Identifier Field: RID
  • Event Type: LINE
  • From-Measure Field: FMEAS
  • To-Measure Field: TMEAS
  • Include all fields from input: TRUE
  • Use M Direction Offseting: TRUE (check this)

6. Convert located_features_ET into a feature class located_features_FC. Detailed steps:

• Run the Make Route Event Layer tool with the parameters:
  • Input Route Fetures: LRS_Routes_selected
  • Route Identifier Field: Route_ID
  • Input Event Table: located_features_ET
  • Event Table Properties:
    • Route Identifier Field: RID
    • Event Type: LINE
    • From-Measure Field: FMEAS
    • To-Measure Field: TMEAS
    • Name of Table or View: located_features_View
• Save the located_features_View (an in-memory data structure ) as a feature class: located_features_FC

7. Prune features from located_features_FC:

• First, select all features from located_features_FC for which the input route identifier (Route_ID) matches the route identifier (RID) of the feature against which it was located, and export this to a new feature class: located_features_FC_pruned. (This excludes all features for which Route_ID doesn't equal RID from the following steps.)
• Second, select all features from located_features_FC_pruned whose Shape_length is 0, and delete them. (Records with 0-length geometry can be artifacts of overlay operations.)

8. Calculate the bearing of the geometry of each feature in the located_features_FC_pruned FC; this takes into account the output geometry. This field is calculated using the same method as in Step (2):

• Calculate the bearing of the located_features_FC_pruned FC using the Add Geometry Attributes tool.
• Rename this field to locd_feats_FC_pruned_bearing using the Alter Field tool.

9. Export located_features_FC_pruned as a table, called located_features_FC_pruned_ET, for use as an input to the Step 11.

10. Export the TMC_proposal feature class as a table: TMC_Proposal_ETbl.

11. Use the Overlay Route Events tool to perform a tabular overlay of TMC_Proposal_ETbl with located_features_FC_pruned_ET, to produce overlay_output_table. The parameters to the tool invocation are as follows:

• Input event table: TMC_Proposal_ETbl
  • Route identifier field: ROPOSAL_LRS_ROUTE_ID
  • Event Type: LINE
  • From-measure field: Begin_Measure
  • To-measure field: To_Measure
• Overlay event table: located_features_FC_pruned_ET
  • Route identifier field: RID
  • Event type: LINE
  • From-measure field: FMEAS
  • To-measure field: TMEAS
• Type of overlay: INTERSECT
• Overlay (output) event table: overlay_output_\table
  • Route identifier field: PROPOSAL_LRS_ROUTE_ID
  • Event type: LINE
  • From-Measure Field: Intersect_From
  • To-Measure Field: Intersect_To
  • Keep zero length line events: TRUE (not sure if this is a good idea)
  • Include all fields from input: TRUE
  • Build index: TRUE

The result of this overlay operation is a table of 'TMC fragments'.

12. Sanity Check: Select all records in overlay_output_table with a Speed_Lim value that is NULL, 0, or 99, and delete them. Note: The Speed_Lim field in this table is aliased to Speed_Limit, which may make it difficult to spot.

13. Add a new field, computed_speed_limit, of type long, to overlay_output_table.

14. Calculate the value of computed_speed_limit. Whether the value of Speed_Lim (speed_limit) or Op_Dir_SL (opposing_speed_limit) is used is determined by whether the two bearings 'align'.

Given that the two bearings are expressed in degrees, the pseudo-code for this is as follows:

	bearing_delta = locd_feats_FC_pruned_bearing - LRSE_spd_lim_bearing
	
	if abs(bearing_delta) < 180 then
		normalized_bearing_delta = abs(bearing_delta)
	else
		normalized_bearing_delta = 360 - abs(bearing_delta)
	end_if
	
	if normalized_bearing_delta > 90 then	
		computed_speed_limit = Op_Dir_SL
	else
		computed_speed_limit  = Speed_Lim
	end_if

15. At this point, we will have a speed limit for each 'TMC piece' resulting from the tabular overlay operation (Step 11). We then proceed to calcuate a speed limit for each entire TMC using the method described Steps (5) throuhg (11) in Approach #1; in summary, these steps are:

• Calcluate a dist for each 'TMC piece'
• Calcuate a travel_time for each 'TMC piece'
• Calcuate a total distance for each entire TMC
• Calcuate a total travel time for each entire TMC
• Calcuate a 'draft speed limit' for each entire TMC, using the $R = D / T$ formula
• Round this value to an integral multiple of 5 MPH (speed limits are integral multiples of 5 MPH)

The details follow:

16. Calcluate a dist for each 'TMC piece': The overlay_output_table contains one record for each 'TMC piece'. Add a new field, dist of type double to this table, and calculate its value as $abs(Intersect To - Intersect From)$. (We need to use the abs function here, because there are cases in which the From measure can be Less than the To measure in an event table.)

17. Calcuate a travel_time for each 'TMC piece': At this point, we have a calculated_speed\limit (i.e., speed) value and a dist (distance) value for each 'TMC piece'. Given this, we can calcuate the travel_time for each 'TMC piece', using the $D = R * T$ formula. Add a field named travel_time, of type double to overlay_output_table. Calculate its value as $dist / speed$.

18. Calcualte the total length (distance) of each TMC, using the Summary Statistics tool. The parameters to the tool invocation are:

• Input table: overlay_output_table
• Output table: tmc_dist_Tbl
• Statistics field: dist
• Statistics type: SUM
• Case field: TMC
  The result of this operation is a table of { TMC, FREQUENCY, SUM_distance } triples. The FREQUENCY column can be ignored for our purposes.

19. Calculate the total travel time along the entire length of the TMC, using the Summary Statistics tool. The parameters to the tool invocation are:

• Input table: overlay_output_table
• Output table: tmc_travel_time_Tbl
• Statistics field: travel_time
• Statistics type: SUM
• Case field: TMC
  The result of this operation is a table of { TMC, FREQUENCY, SUM_travel_time } triples. Again, the FREQUENCY column can be ignored for our purposes.

20. Now that we have the total length and total travel time for each entire TMC, we can calculate a 'draft speed limit' for each entire TMC using the $R = D / T$ formula. Preparatory step: join tmc_dist_Tbl and tmc_travel_time_Tbl on 'TMC', and export the result to tmc_speed_limit_Tbl.

21. Calcuate a 'draft speed limit' for each entire TMC:

• Add a field speed_limit_draft, field of type double, to tmc_speed_limit_Tbl.
• Calculate its value as $SUM dist / SUM travel time$, i.e., using the $R = D / T$ formula.

21. Round the 'draft speed limit' to an integral multiple of 5 MPH. In general, the 'draft' speed limit values may not be integral, and even if integral, the values may not be multiples of 5 (as are speed limits). Add a new field, speed_limit_final, of type long to tmc_speed_limit_Tbl; calculate its value to to $int(5 * round(draft speed limit / 5))$ to ensure that the resulting calculated speed limit is an integral multiple of 5. This gives a speed limit for all TMCs in Massachusetts for which:

• 1spatail successfully conflated the TMC to one or more MassDOT routes, and
• speed limit data was availble in the Speed_Limit event table in the MassDOT Road Inventory

Approach 2 - Final Steps

The final steps entail preparing a shapefile of the NPMRDS TMCs in the Boston MPO region to which are added the following attributes:

• speed limit calculated by 2019 CMP
• speed limit calcluated from 'Approach 2'
• a 'final' speed limit to use in calculating roadway performance metrics required for the Performnace-Based Planning and Programming dashboard.

The steps are as follows:

1. Project the 'Massachusetts.shp' shapefile (the NPMRDS TMC shapefile for Massachusetts) to EPSG:26986.
2. Select the features in (1) that intersect the Boston Region MPO (mpodata.mpodata.CTPS_BRMPO_BOUNDARY_POLY).
3. Export (2) to a new feature class npmrds_tmc_brmpo.
4. Add three new attributes to npmrds_tmc_brmpo, each of type long: cmp_speed_limit, calc_speed_limit, and final_speed_limit.
5. Join npmrds_tmc_brmpo to the table of speed limits produced by the 2019 CMP: cmp_2019_cmp_speed_limit, on 'tmc', keeping all records.
6. Calculate the value of the cmp_speed_limit attribute to that of the speed_limit_ column in the cmp_2019_cmp_speed_limit table; then remove the join.
7. Calculate the value of the calc_speed_limit attribute to that of the final_speed_limit column in the tmc_speed_limit_Tbl table; then remove the join.
8. Populate the speed_limit_final attribute. The basic approach is to use the speed limit from the CMP whenever it is available, even if a different value was calcuated by Approach #2. The rationale for this is that the speed limits calculated for the CMP were subject to review after first having been calculated by an automated process, whereas those from the Road Inventory were the result of an entirely automated conflation. The details:

• Select all records for which cmp_speed_limit IS NOT NULL; set the value of final_speed_limit to the value of cmp_speed_limit . Then clear the selection.
• Select all records for which cmp_speed_limit IS NULL AND calc_speed_limit IS NOT NULL; set the value of final_speed_limit to the value of calc_speed_limit. Then clear the selection.

Finally, export the attribute table of npmrds_tmc_brmpo to a CSV file for use in subsequent analysis and the performance dashboard. Drop all columns except tmc_ and final_speed_limit.

Approach 2 - Summary of Results

The following table summarizes the source of speed limit data (if any) for the 5143 TMCs in the Boston Region MPO area:

Factor	Number of TMCs
Total number of TMCs	5143
Speed limit from 2019 CMP	2853
Speed limit from 2022 Road Inventory using Approach #2	1387
No speed limit	903