Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add update_date specifically for location information #236

Closed
j-d-b opened this issue Jan 20, 2022 · 2 comments
Closed

Add update_date specifically for location information #236

j-d-b opened this issue Jan 20, 2022 · 2 comments
Labels
Needs discussion This issue needs clarification/additional discussion or is inactive New Functionality This item relates to adding new functionality to the specification

Comments

@j-d-b
Copy link
Collaborator

j-d-b commented Jan 20, 2022

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 Clarify usage of 'update_date' property on the FeedDataSource object #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 j-d-b added Needs discussion This issue needs clarification/additional discussion or is inactive Data-content New Functionality This item relates to adding new functionality to the specification labels Jan 20, 2022
@j-d-b
Copy link
Collaborator Author

j-d-b commented Sep 22, 2022

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

@j-d-b j-d-b closed this as completed Sep 22, 2022
@rdsheckler
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs discussion This issue needs clarification/additional discussion or is inactive New Functionality This item relates to adding new functionality to the specification
Projects
None yet
Development

No branches or pull requests

2 participants