Step by Step instructions on how to generate the PCI data collection base data for the HPMS submittal.

1. Cross-section Data Checks

Since a primary driver to the PCI segmentation is the lane counts, we must perform a rather intensive check on the DDOT cross-section data to ensure minor gaps and slivers do not cause the segmentation data to become unnecessarily fragmented. Here's the general workflow for the checkCrossSectionData.py script, which drives the inital segmentation process.

2. Refresh the LRS Cross-Section data

This step involves creating the cross-section union data, which is essentially a summary of the roadway cross-section data. The tool we use for this is Transcend's Segment Analyzer and a template for this process has already been created.

Go to DDOT's Segment Analyzer (DDOT Internal only)
Use Template called CrosssectionUnion_mval
After process is complete, a new table is created in the DDOT LRS database called cross_section_all_mval. If the table already exists in the database, then it will be overwritten by this process.

3. Process PCI Data

How we chop up the routes. We do Large and Small slightly differently

Starting in 2020, the process has been reduced to a single script, with multiple dependent modules. Primary script in Automation/PCI/{YEAR}/ called CreatePCISegmentations.py

Starting in 2020, the cross-section overlay process was consolidated into a single dependent module which is called from CreatePCISegmentations.py. This script is called addCrossSectionSummaries.py in the Crosssections Automation folder.

Preparatory Steps for All Segmentations

Dissolve the Functional Class by type
Make copy of Cross Section Union and update through lane counts (LaneSum)

Large Roadway Segmentation

SegmentationKey = RouteID_Geometry/FeaturePart_SegmentOrder
Functional Class Types:
- Interstates
- Other Freeway and Expressways
Incorporates Functional Class and Lane Count for Segmentation
Does not incorporate the Blocks or Subblocks.

Basic Steps

Filter the Functional Class Dissolve by the above types.
Dissolve by Cross-section lane count.
Union #1 and #2 above to create the base segmentation
Take the Union in #3 and segment each geometry part by .10mi using breakupSegsByDistance function.
Create .10mi segments until done with the FC/LaneCount chunk.
Evaluate 'Change' mileage and process ending event before proceeding to next chunk. (see red info box below)

Handling the 'change' mileage at the end of a segment

If at the end of the route, we are left with a very small (<160 meters) end piece, the script will

Take the 2nd to the last segment and merge with this 'tiny end piece',
This merged new segment is then split into two, equal halves.

Small and Local Roadway Segmentation

SegmentationKey = BlockKey_Geometry/FeaturePart_SegmentOrder
Functional Class Types:
- Principal Arterials (Small)
- Minor Arterials (Small)
- Collectors (Small)
- Locals (Local)
Incorporates RH.Blocks along with Functional Class for Segmentation.

Basic Steps

Filter the Functional Class Dissolve by the above types.
Iterate through the Functional Class Dissolve and find underlying RH.Blocks using the getBlockIDListfromRouteMs function.
1. Iterate through each block found and add to Small/Local segmentation.

"Block not Found" Issue

There may be some segments which indicate "Block not Found". This is likely due to one of the following cases:

They are ramp segments. Ramps are not part of the DDOT "Block" segmentation scheme, so they are going to be in the overlay. This is expected
If they are very small 'sliver' segments, then it's probably slight measure misalignments between RH.Block and RH.LRSE_FunctionalClass.

Cross-Section Overlay

Cross-section data plays heavily in this process. Basically any width or lane type/directionality information is derived from these data. Once the FC is segmented for large and small routes (above), the next step is performed.

Directionality summary (DIRSUM) is updated on the cross_section_all table copy.
Input segments are rendered into midpoints, which are more clean when it comes to LRS overlay.
The midpoint PCI segments are overlayed against the cross_section_all table copy.
Cross-section analysis is performed to provide information on a wide array of items:
- Number of Through Lanes (inbound/outbound)
- Number of Parking Lanes (inbound/outbound)
- Number of Buffered/Barrier features
- Width (in ft) of Through Lanes
- Width (in ft) of Parking Lanes
- Width (in ft) of Buffered/Barriers
- Bike Lanes (various)
- General Directionality of the Segment (DIRSUM)
  - OB - Outbound
  - IB - Inbound
  - BD - Both Directions

Complete Attribute Overlay and Update

The above process sort of takes the segments through the ringer and a few key attributes get washed out after the cross-section part. This last part re-adds the missing data by doing a join to the original table prior to the cross-section.

Additionally, LRS information is overlayed and also added after that:

Ownership
HPMSSection
NHS

2020 Prep Meeting/Discussion with ARA

Click here to expand...

Data elements to provide:
- FC
- Road type (including ramps)
  - Ramps - need unique IDs
  - Service roads - need unique IDs
- Ownership
Oneways
- false oneways
- False twoways
Priority routes
- Interstates
- Freeways
- Principal Arterials
- Minor Arterials
- Ramps connected
- Service connected
Cross-section data
- Run analysis at Block level (midpoint
Data Corrections needed (fix issues related to directionality)

Browser not supported