The business rules for Pavement Sections are maintained by Central Office Asset Management, specifically Todd Shields as of Fall 2020. Generally speaking, a PK needs to reside on current routes and the increasing side of a dual carriage way on County Log if applicable. PKs should not reside on ramps. PKs should be primarily either HMA (flexible) or PCCP (rigid) pavements. As noted in the summary, multiple PKs can be included in planned work, but generally planned work (maintenance or contract) should not be planned for only a part of a PK. They should typically function as an indivisible/atomic unit of pavement locations. If they do need to be divided, the existing PK should be reitred and replaced. There can be multiple records for a single PK if they either ride along a route that has a gap (such as a roundabout intersection) or they ride for a brief period on another route (again like at an intersection).

Regarding fields:

• PAVEMENT_KEY is the identifier (first digit is indicative of district, but the other values don't hold an specific meaning beyond their distinctiveness),

• LOCATION_DESC describes the beginning and end of the route with the route itself typically not referrenced since it is inherent to the route ID,

• ROAD_CATEGORY is generally how much traffic a road has and whether it is interstate or not (see separate Road Category business rules for more information),

• PW_AREA_SYS is pavement area (including shoulders) in sq yds and is expected to be populated systemiatically based on information from dTIMS,

• PS_AREA_SYS are similar to PW_AREA_SYS but are expected to be generated when a project is developed, when a new PK is created, or whenever such value is calculated and will function as manual overrides to the systemically derived values from PW_AREA_SYS

• The remainder of the fields are standard for event layers on RAH

Please note that LRSE_Pavement_Section is the old version of this data from prior to the conversion from State Log to the current version of County Log/One Log.