search

usdot-jpo-ode / wzdx

The Work Zone Data Exchange (WZDx) Specification aims to make harmonized work zone data provided by infrastructure owners and operators (IOOs) available for third party use, making travel on public roads safer and more efficient through ubiquitous access to data on work zone activity.
Creative Commons Zero v1.0 Universal
89 stars 62 forks source link

Add update_date specifically for location information #236

Closed j-d-b closed 1 year ago

j-d-b commented 2 years ago

Background

There is an update_date property several places in the specification: the FeedInfo, FeedDataSource, RoadEventCoreDetails, and FieldDeviceCoreDetails.

In each object, the property is defined as: "The UTC date and time when the was last updated."

There are two issues with this:

  1. It is not clear when the value should be updated (see #184).
  2. It is not possible to know what changed.

Item 1. should be addressed by #184—this issue seeks to partially address 2. by proposing an update date specifically for location information.

This issue was spawned from subgroup member discussion specifically in regard to desire to know when the location (e.g. geometry, road_names) was updated. We do not want to add too much granularity to update_date—a specific update_date for each property is not necessary, but one for location may be desirable as this is arguably the most important features of a road event.

Potential solutions

This could be accomplished by simply adding a new location_update_date property to the RoadEventCoreDetails, and FieldDeviceCoreDetails. It could be more complex, such as being added to a location-specific object similar to what is proposed in #233.

Drawbacks

While we want WZDx to meet the desires of producers and consumers and be powerful with optional properties to enable advances consumers to provide higher specificity, we also want to keep it simple and easy for new users to understand. Adding a new optional property to describe when location information was updated doesn't break backwards compatibility, but it does add complexity so it should be important to many consumers for clear reasons before it is implemented. This issue was created to ensure discussion was documented, as the concept of a "location update date" was brought up several separate times, but there it will not be prioritized until there is substantial demand.

Next Steps

  • Determine if knowing when the location information of a road event or field device is still desired by consumers.
  • Discuss and expand on possible implementations.
j-d-b commented 1 year ago

Closed due to lack of interest and not obvious benefit to users.

rdsheckler commented 1 year ago

We actually use this in our internal systems on a regular basis. Location is one of those things that change when nothing else has changed. Aside from updating the location with additional accuracy due to more constellations passing by there are real changes for moving work zones. Such as, an arrow board that was used in a moving lane closure changes its location by the minute when nothing else has.

  • © Githubissues.
  • Githubissues is a development platform for aggregating issues.