Process for Connecting Centerline to MAR

Owned by Former user (Deleted)
08 Feb, 2022
4 min read

Background

Since its inception, the Master Address Repository (or MAR) has used DDOT's roadway centerline to reference the street blocks.  Historically, they have used a copy of DDOT's Street Segments.  More recently, with the implementation of MAR 2.0, the MAR system is transitioning to DDOT's newer segmented roadway data:  Roadway Blocks and Subblocks, which are part of the collection of segmented roadway data.  

Data

As mentioned above, the DCGIS MAR team makes use of DDOT's Roadway Blocks and Subblocks.  The primary key for Blocks is BlockKey; for Subblocks it is SubblockKey. 

For ADDRESSES (DCGIS.ADDRESSES_PT) in the MAR database, 

  • Standard street addresses are populated with both BlockKey and SubblockKey
  • Alley addresses are populated only with SubblockKey (because an alley address is not on a street and only streets have BlockKeys)

For the BLOCK range table (DCGIS.BLOCKS_PT) in MAR database,

  • Street blocks are populated with their corresponding Blockkey value from the DDOT RH.Block table
  • Alley blocks are not populated with a corresponding Blockkey value from the DDOT RH.Block table

What is Directional 'Side'?

Here's a breakdown of polylines in GIS:

  1. All GIS polylines have a start point and an end point. 
  2. Typically, GIS users will typically refer to a GIS polyline's direction as either 'with' or against the centerline's digitized direction
  3. A polyline begins with the start point and proceeds to the end point. The direction from the begin point to the end point is the geometry direction.
  4. As a polyline ascends, it also has a right or a left side.

In GIS, it is useful to find relationships based upon the relational 'side' of the roadway.  For DDOT, this is especially useful for identifying curbside assets like signs, parking zones, streetlights and parking meters.  Prior to the advent of GIS, DDOT field technicians have used "odd side" or "even side" to describe the location of these assets.

Take a look at the example below to understand how directional side works:

  • The odd-numbered houses are on the right side of the street polyline - in DDOT we call this the Outbound side
  • The even-numbered houses are on the left side of the street polyline - in DDOT we call this the Inbound side

Need for Directional 'Side'

  • The MAR database maintains address ranges by describing "LEFT" or "RIGHT", but that does not relate to the geographic side of the street.
  • The MAR database does not have the ability to determine whether a specific address is on one side of the street or another.
  • NOTE: the related GIS address point can derive this relationship spatially, but it requires additional processing/analysis.

Finding MAR Directional Side

DDOT has developed a Python script which checks each MAR address point and finds its relationship to the DDOT Block centerline geometry.

Analyze Individual Address Points

Make a local copy of DCGIS.ADDRESSES_PT, analyze each point.  Here is a high-level overview of the initial process:

  1. Examine each GIS address point in a copy of the DCGIS.ADDRESSES_PT feature class.  For each point,
  2. Get the associated DDOT Block polyline according to the Blockkey in ADDRESSES_PT

  3. Perform geometry relation using the arcpy.polyline method pointFromAngleAndDistance (see here for more info)

    1. pointFromAngleAndDistance provides both the point's distance and what side it is located on.
    2. If True, point is on Right
    3. If False, point is on Left
  4. Indicate DDOT LRS side, based upon the geometry relation in #3.
    1. If Right - this is the DDOT outbound side (OB)
    2. If Left - this the DDOT inbound side (IB)
  5. Indicate if address number is Even or Odd
  6. The resulting table (DDOTSGIS.ROADWAY.MARQC_Side) is then used by OCTO staff to join to the DCGIS.ADDRESSES_PT table for update, if needed:
    1. LRS_SIDE:  values - IB/OB

Summarize Address Points

Summarize DCGIS.ADDRESSES_PT local copy, and determine the predominant LRS directions for the address odd/even side.  Also capture the percentage match of the 'winner'.

Understanding Percentage Match

Not all address ranges are perfectly uniform.  There are some cases where you can find both odd and even on the same side of the block.  These cases are rare, but documenting the "Percentage Match" let's us know where odd and even-numbered addresses are not perfectly uniform.

For example if 8 out of 8 even-numbered address point fall along the LRS inbound (IB) side, then the LRS_SIDE_EVEN_PERCMATCH value will be 100.  On the same block, if 8 out of the 10 odd-numbered address points fall on the LRS outbound (OB) side, then LRS_SIDE_ODD_PERCMATCH  will be 80


These values are stored in the fields LRS_SIDE_EVEN, LRS_SIDE_ODD:

AttributeDescription

OUTBOUND-ALL 

All addresses are found only on the outbound side

INBOUND-ALL

All all addresses are found only on the inbound side

OUTBOUND-MAJORITY 

Most of the addresses (>50%) are found on the outbound side

INBOUND-MAJORITY

Most of the addresses (>50%) are found on the outbound side

INBOUND-TIE

An equal amount (=50%) of address points are found on both sides

OUTBOUND-TIE

An equal amount (=50%) of address points are found on both sides

INBOUND-THEORETICAL 

If no addresses are found on a the inbound side AND a majority or all of the address points are found on the outbound side.

OUTBOUND-THEORETICAL

If no addresses are found on a the inbound side AND a majority or all of the address points are found on the outbound side
-

If only even or odd addresses are found on both sides of the street and they result in a tie (INBOUND/OUTBOUND-TIE)?


The fields LRS_SIDE_EVEN_PERCMATCH, LRS_SIDE_ODD_PERCMATCH contain the % of highest match for addresses on a given side.

The resulting table (DDOTSGIS.ROADWAY.MARQC_SideSummary) is then used by OCTO staff to join to the DCGIS.BLOCKS_PT table to update relevant fields:

  1. LRS_SIDE_ADDRESS_EVEN
  2. LRS_SIDE_ADDRESS_ODD