WZDx v3 Specification Update Subgroup Meeting Notes, 2020 07 09 - usdot-jpo-ode/wzdx GitHub Wiki

Virtual Attendees

  • Dan Oesch - Missouri DOT
  • SIVA NARLA - ITE
  • Hua Xiang - Maryland DOT
  • Wesley Alford - USDOT Volpe
  • Polly Okunieff - ICF
  • Kellen Shain - Noblis
  • Neil Boudreau - MassDOT Highway
  • Valerie Shuman - SCG
  • Ross Sheckler - iCone
  • Michael Hanowsky - Woolpert
  • Colleen Bond
  • Yang Cheng - Wisconsin DOT
  • Kali Fogel - Los Angeles Metropolitan Transportation Authority
  • Sabrina Mosher - SwRI
  • Jim Williams - INRIX
  • Mark Mockett - Volpe Center
  • Sinclair Stolle - Iowa DOT
  • Michelle Boucher - IBI Group
  • Nisar Ahmed - MTC
  • weimin huang - HERE
  • David Rush - Virginia DOT
  • Thomas Craig - Trillium Transit
  • Tom Stidham - Wash DOT
  • chris brookes - MDOT
  • Rob Hoyler - TomTom
  • Molly Behan - Volpe
  • Justin Belk - WSDOT HQ Traffic Operations
  • Skylar Knickerbocker - Iowa State
  • Erik Davis -TomTom
  • Chuck Felice - UDOT
  • Lynne Randolph - SwRI
  • Luke Urie - City of Austin
  • Julia Lien - Booz Allen Hamilton
  • Eli Sherer - GEWI
  • David Craig - GM
  • Christopher Butler - Q-Free
  • Pier Castonguay - Ver-mac
  • Adam Carreon - ArizonaDOT
  • Sabrina Mosher - SwRI
  • Eric P Ricciardi - Booz Allen Hamilton
  • Jacob Brady - IBI Group
  • Nate Deshmukh Towery - Volpe
  • Derald Dudley - USDOT/BTS
  • Mahsa Ettefagh - Booz Allen Hamilton

Purpose and Intended Outcomes:

  • Discuss prioritized list of issues and new pull requests
  • Gather group feedback on the proposed solutions for consideration in v3
  • Finalize pull requests for prioritized issues by June 15th
  • Provide feedback on pull requests

Agenda

  • Sign-in and Welcome
  • Prioritized Issues and New Pull Requests for v3 Specification
  • Action Items and Next Steps

Discussion Summary

Prioritized issues and new pull requests to be considered in v3 specification were presented to the members and feedback was requested. There prioritized issues and comments received from attendees during the meeting are listed below.

  • Issue #112 – Adopt Object Oriented Data Modeling

    • No comments

  • Issue #111 – Add Elevation Data to All Reported Positions

    • Kali Fogel: How is elevation anticipated to be implemented by operations that would be working on the rodway?
    • Michael Hanowsky (Woolpert): Re the elevation data, how would conflicts caused by elevations that are different from the roadway be handled? There seems to be the potential for confusion and conflicts.
    • Jacob Brady: Micheal, thanks for the question. We are not diving into the business rules behind adding elevation yet. The key thing to note here is that GeoJSON allows adding elevation to a coordinate and as WZDx conforms to GeoJSON, it is also allowed. How it is used/the accuracy of that, alike to 2D coordinates, is up to the implementer
    • Ross Sheckler - iCone: Much of the value that is gained with elevation data is already present if the road name is properly entered.
    • Michael Hanowsky (Woolpert): @Ross - that's my thinking, as well. And concern that adding elevation here creates and opportunity for data to conflict. I'm not sure I understand how the use cases proposed could not be handled through data of the underlying roadway.
    • David Craig @ GM: Ross, I totally agree that Road name can solve many issues here, the problem occurs when a road has multiple names. Elevation can solve this mis-alignment of names.
    • Ross Sheckler - iCone: As a data generator we are very careful to avoid providing data where common issues with accuracy might cause other problems. If we were to get elevation wrong by 3m that is the height of many overpasses and would put us on the wrong road. We don't do compasses for the same reason, the accuracy issues cause all sorts of problems.
    • Valerie Shuman - SCG for ICF: CORRECTEd: For elevation: interoperability testing in a multimap environment has shown that multiple types of location data (name, lat/long/elvn, etc.) are needed to provide consistently correct loc ref. See OpenLR for example
    • David Craig @ GM: Ross, let's please take this to GitHub and get all of this documented. But, generally speaking, more data is always better. Yes, I agree there could be specific examples where 3m of error could snap a point to an incorrect road. But, snapping a line string to an incorrect road is much more difficult, even with elevation errors. The relationship of the elevation is usually what is important. Meaning seeing that it is a rising elevation road helps indicated that you are talking about the ramp, not the access road. So, like I said, let's take this to GitHub and document all of your concerns. Thanks!

  • Issue #108 - Replace the Subidentifier Field with a Relationship Object

    • Kali Fogel: Is the parent/child anticipated to be a dynamic assignment or is a national standardard being considered and maintained or exists?
    • Polly Okunieff (ICF): does the relationship object refer to an identifier that is already stored in the file. The original concept was to provide an internal identifier that points to an internal file at a agency. The subidentifier was to group parts of a major project. I think project number would work. Agencies will need to track messages about each project.
    • Neil Boudreau, MassDOT Highway: We used different contract numbers for each of the unique parts of the large construction effort
    • Nisar Ahmed: i think the idea of the subidentifier is to provide a link to something that is not an event or feature that can be described in the WZDx
    • Eli Sherer: So would this relationship possibly include a "Project" and multiple "Phases"?

  • Issue #82 - Include Detour Information

    • Michelle Boucher, IBI Group: For issue #82, I agree that a required field called type is added t the road_event object. This will set the spec up for adding other "types"in the future.

Kali Fogel: Has licensing of the data been considered in the feed. The MDS project has the concept of licenses and so does GTFS.

Valerie Shuman - SCG for ICF: have we looked at the FGDC-approved ISO standards for metadata so that we stay consistent?

Valerie Shuman - SCG for ICF: Thanks! There have been some relatively recent update that might apply... not sure

Derald Dudley (USDOT/BTS): Thansk Valerie. Do you have a link?

Ross Sheckler - iCone: David, I agree we need to document this. It is an issue that equipment companies will have. We want to be careful that we only share 'facts' so that errors don't float up as aggregators put pieces together.

Polly Okunieff (ICF): Can lane #1 be the shoulder?

Lynne Randolph (SwRI): I do think knowing about the shoulders is useful

Polly Okunieff (ICF): What about bike lanes?

chris brookes MDOT: You are missing hard shoulder running (lanes), and HOV lanes.

Eli Sherer: There should also be reference to the same conditions with HOV lanes. HOV is very often to the left (#1), but there might be a shoulder or breakdown lane between the HOV and Left regular travel lane.

Sabrina Mosher (SwRI): We would also like to see HOV lanes.

Lynne Randolph (SwRI): I think I sent TxDOT's lane types

Eli Sherer: So left regular travel lane would be #3

Lynne Randolph (SwRI): if the images went into the issue

Polly Okunieff (ICF): do we need to describe the functional use of the lane (HOV, bike, bus only)

Eli Sherer: Yes!

Lynne Randolph (SwRI): we also have express lanes

Valerie Shuman - SCG for ICF: Are there also business rules that define how to handle temporary tapers/temp allowed shoulder running (eg by transit) in this lane description?

Eli Sherer: Is "shoulder" the equivalent of a Breakdown lane?

Kali Fogel: As a layman a shoulder is not a lane.

Michael Hanowsky (Woolpert): The question of what is a lane is much broader than just work zones.

Lynne Randolph (SwRI): that wouldn't fit your width rule then

Lynne Randolph (SwRI): bike lanes

Nisar Ahmed: For the purpose of WZDx, the fundctional purpose of a lane may not be as important. Also, the width of a lane is not important as bike lanes can be narrower.

Sabrina Mosher (SwRI): I would say that shoulder isn't a lane, but it might be relevant to a data consumer to know if the left or right shoulder is closed.

chris brookes MDOT: a shoulder can function as a lane and often set-up to be used during peak hours, then a shoulder outside of that time.

Polly Okunieff (ICF): perhaps we want to separate the function from the position

Lynne Randolph (SwRI): TxDOT labels the type and the index both

Valerie Shuman - SCG for ICF: Functional purpose is important if it impacts use permissions by vehicle type

Sinclair Stolle (Iowa DOT): Also, shoulders beging closed can impact wide loads

Kali Fogel: is occuring, not define how a jusridiction view their road netwrok.

Eli Sherer: Current configuration I-91 near Hartford, left to right: HOV, "no crossing lane" (often used for disabled), Left travel, center travel, right travel, Breajdown lane.

Nisar Ahmed: For WZDx, shoulder is important.

David Craig @ GM: Traditionally, most bike lanes are 1.5m wide. That is how we landed on the 1m for the limit of what counts. So, bike lanes would show up as a unique individual lane .

Eli Sherer: Also in some areas, the Shoulder or Breakdown lane CAN be used for travel at time (e,.g. during rush hours)

Lynne Randolph (SwRI): If you have indices, you shouldn't need left/right designators

Lynne Randolph (SwRI): we have issues when we, for example, have three right exit ramps

Kali Fogel: bidirectional is ambiguous.

chris brookes MDOT: local expres are needed for split merge work zones

Michael Hanowsky (Woolpert): How would you handle the case of a shoulder with a width that is temporarily reduced as the roadway passes over a bridge?

Kali Fogel: Why restrict what values users can be included. They should be able to add any they want and TMDD allows for locat values to be referenced.

Eli Sherer: Maybe apply numbering ONLY to "Travel lanes"?

Kali Fogel: It like saying buweekly.

Mahsa Ettefagh - Booz Allen Hamilton: Press *6 to unmute your line

Neil Boudreau, MassDOT Highway: I see that "Connector Road" is included in the list, but is intended to refer to a "Collector/Distributor Road (C/D Road)?

Lynne Randolph (SwRI): no

chris brookes MDOT: no center lane is seperate

Skylar Knickerbocker (Iowa State): I think that is the functionily we are looking for

Lynne Randolph (SwRI): reversible lanes are very specific in usage, IMO

Rob Hoyler - TomTom: Shoulders should be referenced, but not numbered as lanes. Lanes should all have consistent surface types & speed/navigability expectations., as standard travel lanes.

Ross Sheckler - iCone: We do need to be able to describe flagging operations with a single lane, reversing.

Lynne Randolph (SwRI): we designate those as turn lanes normally

Neil Boudreau, MassDOT Highway: That is a TWLTL where you can turn left from either directions

Skylar Knickerbocker (Iowa State): @Ross we have that with alternating-flow-lane

Sabrina Mosher (SwRI): I've always heard those called turn lanes

Valerie Shuman - SCG for ICF: have we looked at the ISO GDF updates for lane definitions? I believe they were working on this a bit lately

Kali Fogel: It is a turn lane, not a lane of travel.

Hua Xiang - Maryland: We called Two-Way Left-Turn Lane

chris brookes MDOT: reversible-lane and center left turn lane need to be listed as seperate, as they are functioning differently.

Hua Xiang - Maryland: TWLT Lane, it is

Skylar Knickerbocker (Iowa State): @chris agree

Kali Fogel: No, it is not a reversible or bidirectional lane. It is a turn lane.

Hua Xiang - Maryland: They have to be seperate. SUpport that reversible lane is AM/PM reversal setup

Rob Hoyler - TomTom: Agree with that "reversible lane" comment (no turn expectations).

Lynne Randolph (SwRI): I would agree with that

Lynne Randolph (SwRI): removing left/right

Lynne Randolph (SwRI): shouldn't all lanes be defined? not just the ones affected

Sabrina Mosher (SwRI): If there is a roadway with 5 lanes. 2 in each direction and 1 turning lane, and the whole roadway was closed, how would this lane table then handle that? Would it just have to be assumed based on the shoulders and turning lanes the direction of travel in each lane?

David Craig @ GM: I believ shoulders need to be numbered. Often these shoulders are used during construction activities and having them numbered makes reporting the lane reassignments much easier. Additionally, it is much easier to report when the shoulder and lane are closed together.

Lynne Randolph (SwRI): agree w/David

David Rush: Agree with David. We have shgoulders which are trave lanes during certain time of the day.

Hua Xiang - Maryland: Thank you everyone.

Rob Hoyler - TomTom: Agree with shoulders which are travel lanes as well during certain times

Action Items and Next Steps

  • Provide feedback on the prioritized issues and pull requests discussed today (these will have the green ‘v3’ or ‘v3 Candidate’ tags on GitHub)
  • Create final pull requests for consideration in next version of the spec.