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

Clarify units for reduced_speed_limit #169

Closed
j-d-b opened this issue Apr 14, 2021 · 6 comments · Fixed by #174
Closed

Clarify units for reduced_speed_limit #169

j-d-b opened this issue Apr 14, 2021 · 6 comments · Fixed by #174
Assignees

Comments

@j-d-b
Copy link
Collaborator

j-d-b commented Apr 14, 2021

Issue

The reduced_speed_limit property on the RoadEvent object is an Integer value defined only:

The reduced speed limit posted within the event space.

There is no mention of units. As the reduced_speed_limit must be an Integer, it is not possible to include units within the value (e.g. "35 mph"). As WZDx moves towards including traffic data with the activities of the Smart Work Zone Subgroup, this needs to be addressed.

Solutions

The following are several options for clarifying the units for reduced_speed_limit:

  1. Include a recommendation in the text description that reduced_speed_limit should be in a certain unit, e.g. mph. This is non-binding but helps get things started and does not require an official specification change.
  2. Require a certain unit for reduced_speed_limit specifically.
  3. Add a property to the road event for reduced_speed_limit_units and associated new enumerated type SpeedUnits, to be used here and elsewhere as the spec expands.
  4. Require a certain unit for all speed values in WZDx (which is only reduced_speed_limit now).
  5. Allow specifying the units for speed in the RoadEventFeedInfo which applies to all information in the feed. This allows producers to choose at the top-level what unit their used in the feed information. An example implementation of this would be adding a new property speed_units to the RoadEventFeedInfo.

I have not yet checked what other standards do in regards to speed information units, but if WZDx is going to be expanded to include traffic information my first thought is that option 4. is the cleanest as it allows consumers to compare feeds from different producers easily without checking other fields for units and doing conversions.

@daylesworth
Copy link

daylesworth commented Apr 14, 2021

@j-d-b, another variant of option 4 (and others) is to make the units property optional and specify a default value in the standard (probably "mph").

FYI, J2735 specifies speed values (Velocity) as an integer in units of 0.02 m/s (probably not a good choice here). Google's Roads API has an optional "units" parameter that can be set to kph or mph (defaults to mph). OpenStreetMap includes the units in the maxspeed field only if it's not kph (e.g. "60" = 60 kph, "50 mph" = 50 mph).

@lynnerandolph
Copy link

lynnerandolph commented Apr 14, 2021 via email

@DeraldDudley
Copy link
Collaborator

Consider implementing #155 then add reduced_speed_limit to the Restrictions Class.

@j-d-b
Copy link
Collaborator Author

j-d-b commented Jun 24, 2021

Based on some of the above comments and co-chairs discussion the preferred approach is to indicate that reduced_speed_limit must be in miles per hour.

@sergebeaudry
Copy link

sergebeaudry commented Aug 12, 2021

--just put the same comment in in the pull request #174 comment there instead

If we want WZDx to become an international standard. the current suggestion will halt its adoption. An alternative that cost nothing in the standard per say but effort on the data user is to define it as using the unit standardized at the defined location.
EX: the roadevent is in USA = MPH, From Canada= KPH.
Would be nice to understand how the mapping/Automaker companies are managing the speed currently across the world.

@j-d-b
Copy link
Collaborator Author

j-d-b commented Dec 16, 2021

Completed in #195.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants