2021 09 23 Specification Update and Specification Extension Subgroups

Meeting Information

September 23, 2021, 1:00-2:00pm EDT

Purpose

Review and discussed proposed changes to how road events are represented in the specification (Issue #203, PR #209). Review and discuss other pull requests.

Agenda

Sign-in and Welcome PR #209 – RoadEvent refactor Other PR Updates & Discussion Outstanding Issues for Next Cycle Wrap-Up and Next Steps

Minutes

PR #209 – RoadEvent refactor

Background

Data Modeling Best Practices: First Normal Form – Don’t comingle objects/features Efficiency: Exchange only the data needed
Scalability

• Normalized data is easier to scale
• Enables other types of road events (e.g. restrictions)
• Compartmentalization eases maintenance

Proposal

• Describe the core details that are shared by all specific types of road events (such as work zones and detours) by a RoadEventCoreDetails object, which is used by all types of road events. These details were extracted from the all-encompassing RoadEvent.
• Define a WorkZoneRoadEvent object for work zone road events.
• Define a DetourRoadEvent object for detour road events.
• Modify the RoadEventFeature to allow the ‘properties’ property to be either the WorkZoneRoadEvent or DetourRoadEvent object.
• Remove the all-encompassing RoadEvent.
• Move the ‘location_method’ property from the RoadEventDataSource object to the WorkZoneRoadEvent object.

Examples

New work-zone example

"id": "71234",         
"type": "Feature",         
"properties": {
	“core_details”: {
		"data_source_id": "1",
		"event_type": "work-zone",
		"road_names": [               
			"I-80, I-35"            
		],
            		"direction": "northbound",
		 "description": "Single direction work zone",
		"creation_date": "2009-12-31T18:01:01Z",            
		"update_date": "2009-12-31T18:01:01Z"
	},
	"beginning_milepost": 125.2,            
	"ending_milepost": 126.3,            
	"beginning_accuracy": "estimated",            
	"ending_accuracy": "estimated",            
	"start_date": "2010-01-01T01:00:00Z",            
	"end_date": "2010-01-02T01:00:00Z",            
	"start_date_accuracy": "estimated",            
	"end_date_accuracy": "estimated",            
	"event_status": "active",            
	"vehicle_impact": "some-lanes-closed",            
	"reduced_speed_limit": 55,            
}  

New detour example

"id": “67890-detour2",         
"type": "Feature",         
"properties": {           
	“core_details”: {
		"data_source_id": "1",
            		"event_type": “detour",
            		"relationship": {               
			“parents": [                  
				"67890“
			],                  
			“first”:[
				"67890-detour1“
			],                  
			“next”:[
				"67890-detour3"               
			]            
		},
		"road_names": [               
			“US 69"            
		],
          	  	"direction": "northbound",
		"description": "Detour for road event 67890, second segment.",            
		"creation_date": "2009-12-15T14:01:01Z",            
		"update_date": "2010-01-01T01:03:01Z"
	},
	"beginning_cross_street": "NE 126th Avenue",            
	"ending_cross_street": "IA 210",            
	"beginning_accuracy": "estimated",            
	"ending_accuracy": "estimated",	
	"start_date": "2010-01-01T01:03:01Z",            
	"end_date": "2010-06-30T01:00:00Z",            
	"start_date_accuracy": "verified",            
	"end_date_accuracy": "estimated",            
	"event_status": "active",            
}

Vehicle_impact property is NOT an element of a Detour event, was previously a required property of a RoadEvent

Discussion

Craig Moore: What was the logic on not moving more fields over? Cross street, milepost, accuracies related to those locations

• Derald: I thought about this from a restrictions event - if we had to describe a road event that went beneath a bridge that had a low clearance, we could segment only a bit of the road before and after the bridge. Core details are minimum content necessary to locate and identify a road. Geometry is in the feature event, but other road attributes such as the road name and direction of travel were the main relevant properties needed to describe all road events. Beginning/ending accuracy are specific to a work zone that begins and ends, not how linear events are described in GIS world.
• Craig: Spatially if a feature doesn't align with the beginning and ending cross streets (could be a bigger extent than the feature itself), but is that actually a problem for data consumers to process? Compared to the geospatial feature that it's describing? That may need to be clarified in the specification.
• Derald: It was in my mind that segmentation begin and end at intersections and mileposts, but that's not how the specification actually works. Segmentation occurs whenever a property changes, not just at intersections - beginning and ending cross streets might not be relevant to all event types.
• Craig: The overall concept is great, but we can dig deeper into which fields need to move across. Start/end date?
• Derald: We didn't add start/end dates because restrictions are often persistent, so they're linear event but not a temporal event. Start/end date don't help describe a restriction or other persistent features
• Craig: Consumers need a required field and need to know when to act on it (will be present in every record). I agree now about cross street and milepost

Eric: As a consumer, the most important component is the geometry itself. Cross streets are important context, but we only use it for correcting

Jacob: This comes to do with the definition of cross streets, which may not exactly match the geometry of the road event, but be close by. In that case, it could go in the core with a clearer description of "nearest" or "last" cross street, but might not be defined as such right now

Derald: Anytime a name changes, you have to segment the road with a name and direction. If we ever get to the point of publishing named roads, you wouldn't need those start/end dates for persistent characteristics.

• Craig: If we're talking the core details of an event, then there should be dates. Talking only about roads this makes sense, nothing about the temporal definition.
• Jacob: We decided that the core details are the core details of a road event. To represent just a road we would want another event
• Craig: If that's the case, adding the temporal piece is important.
• Jacob: For a restriction event, start/end date of a low clearance isn't defined. You could make one, but they don't have defined end dates.
• Craig: That goes back to whether we want to focus on the road, or changes to the road. That's a bigger discussion. Describing my jurisdiction's road network is a big deal
• Derald: We've discussed this as maximizing the extensibility of the specification. This specification provides that and enables that publication. Are we crossing the line between temporal and linear events? Yes, I think it's good because we draw more folks into the spec. I don't think this is used to describe the network at its core, but that model could be influenced by what we do here.
• Craig: That brings us into a fundamental clash with other folks describing road networks. Bringing in people is good, but we need to be careful where we draw the line.

Ross: this will be useless if we go beyond the work zone/temporary events. This will never get done. We need to be a lot stronger about what our mission is, because we're already into scope creep and we're only in our 3rd year.

• Derald: If we can leverage the specification to improve safety or enhance efficient travel, there's social benefit there. We need to be concerned about scope creep, but that's why we're having these discussions.

Faisal: This becomes a resources issue for us, requiring additional info. I'm worried that it will scare people out of the effort.

• Craig: Opening up to a permanent restriction moves the spec toward describing the road network in its default state. Start/end date as a required field pre-empts how far the spec can go.
• Craig: Another of other events fit into that temporal box (like a marathon). We assume the AV is loaded with the default state of the roadway, and this represents changes to the default state.
• Faisal: 511 already has roadway network information there.

Ross: There's nothing preventing creating a restrictions data exchange that don't need to be in here or vice versa. The value here is for work zone data,

Jacob: I'm in support of adding start/end date to the core details and keeping WZDx focused on temporary road events

• Ross: Being able to define an end date is a great way to define temporary ness

Nate: Do people have thoughts on how additional events could be integrated in parallel?

• Derald: There's been a lot of good work, and if we can leverage it to save lives in other places, then we should take that opportunity. If we can look at the work zone spec, tweak it to make things safer/better, then why stop that?
• Craig: The core details open up the extensibility. You could make it work for New York's case, but then you bump into other people's space and muddies our mission/vision

Nate: Going back to GTFS, there are many extensions that have emerged that maybe don't muddy GTFS. Allow sharing other information that's relevant to transit but isn't the schedule, arrival times. I'm receptive to Derald's point. If there's a way to share corollary things without muddying how we share core things, then we should try.

• Dave: I liked the core elements that are required to make a work zone data event. That's kinda where we started
• Craig: It boxes us to not describe everything on the road.
• Derald: It does inhibit other people using the spec.

Other PR Updates & Discussion

#174 Reduced Speed Limit units

• Presented at July subgroup meeting using MPH
• Following more discussion among co-chairs, change units to km/h instead of MPH to follow other standards and industry usage
• Rename reduced_speed_limit property to reduced_speed_limit_kph
• Still clarifies that reduced_speed_limit_kph only needs to be supplied if speed limit within road event is lower than the posted speed limit.

#188 Refactor and clarify Lane types

The following changes were made to the LaneType enumerated type:

• Rename lane to general
• Remove right-turning-lane and left-turning-lane
• Remove right-exit-lane and left-exit-lane
• Add exit-lane
• Remove right-exit-ramp and left-exit-ramp
• Add exit-ramp
• Remove right-entrance-ramp and left-exit-ramp
• Add entrance-ramp
• Add entrance-lane
• Add parking
• Add median

#196 Additional Vehicle Impact values

Implemented as previously discussed

#198 Use Restriction object on Road Events

• Rename LaneRestrictionUnit enumerated type to UnitOfMeasurement, which allows more general use
• Rename the RoadRestriction enumerated type to RestrictionType which is more semantic
• Rename the LaneRestriction object to Restriction which allows more general use
• Remove the lane_restriction_ prefix from the properties of the Restriction object
• Change “units” (on Restriction object) to be singular “unit”
• Change the restrictions array on the RoadEvent object to be a list of the Restriction object rather than a list of the RestrictionType (the key change from this PR: road events can now have restrictions with a value and unit)

#199 Deprecate Location Verify Method

After previous meeting determined GPS device should be required for verification
Changes include:

• Depreciate location_verify_method
• Redefine SpatialVerification enumeration to clarify verified should use a GPS enabled device

Other discussion

• Change begin/end accuracy to Boolean
• Verification is still missing a frequency (i.e. a manually collected GPS reading vs continuous reporting) but may be addressed with a future field

Outstanding Issues for Next Cycle

• #125 – Mobile work zones
• #184 – Require update_date on the RoadEvent object
• Both discussed at July subgroup meeting
• #189 – Remove unneeded values from EventStatus enumerated type
• #194 – Clarify geometry requirements
• #197 – Refactor relationship object
• #201 – Replace beginning_accuracy and ending_accuracy with positional_accuracy
• #207 – Use UUIDs for feature IDs

Action Items

Action items before next meeting:

1. Participate in discussion on pull requests on GitHub and add comments, suggested edits, and any other feedback.
2. Join the Work Zone Data Working Group meeting on November 2nd, 12:00-2:30pm EDT
   1. Email [email protected] if you have not received an invite.

Participants

Name	Organization
Dave Craig*	General Motors
Eric Kolb**	Google
Jingwei Xu*	HERE Technologies
Jacob Brady*	IBI Group
Skylar Knickerbocker*	Iowa State University
Derald Dudley**	USDOT Bureau of Transportation Statistics
Adam Carreon	Arizona DOT
Marty Lauber	Arizona DOT
Mahsa Ettefagh	Booz Allen Hamilton
Jenny Ghasy	Google
Jeremy Agulnek	HAAS Alert
Pete Krikelis	Hill and Smith
James Cullins	Hillsborough County
William Twaite	Hillsborough County
Michelle Boucher	IBI Group
Ross Sheckler	iCone
Sinclair Stolle	Iowa DOT
Brandon Saylor	Kentucky Transportation Cabinet
Alexander Lemka	Maricopa County DOT
Faisal Saleem	Maricopa County DOT
Neil Boudreau	Massachusetts DOT
Chris Brookes	Michigan DOT
Meredith Nelson	Michigan DOT
Timothy Fiato	New York State DOT
Chris Parker	Pennsylvania Turnpike
Devorah Henderson	Qlynx
Eneliko Mulokozi	Regional Transportation Commission of Southern Nevada
John Copple	Sanborn Map Company
Craig Moore	Seattle DOT
Jianming Ma	Texas DOT
Rob Hoyler	TomTom
Jaime Hutton	TomTom
Yaw Adu-Gyamfi	University of Missouri
Yang Chang	University of Wisconsin-Madison
Jeff Purdy	USDOT Federal Highway Administration
Hadrian Merced	USDOT Volpe Center
Mark Mockett	USDOT Volpe Center
Chuck Felice	Utah DOT
Pier Castonguay	Ver-Mac
David Rush	Virginia DOT
Tom Stidham	Washington State DOT
Erin Schwark	Wisconsin DOT
Gopal Raju
Tom Shlarman

* Co-chair of Specification Update Subgroup
** Co-chair of Specification Extension Subgroup