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

Marked Location Object with road_event_id #224

Closed sknick-iastate closed 2 years ago

sknick-iastate commented 2 years ago

Issue name: “Marked Location Object with road_event_id”

Summary

Currently in the smart work zone device feed (SwzDevice) the MarkedLocations Object has an optional field to provide the road_event_id. In addition to that the FieldDeviceCoreDetails already includes the ability to also provide an array of road_event_ids. This seems redundant since the information could be located in two different locations for these types of devices which are both optional.

Because the marked_locations allows for an array, I assume the use case for this is that a marked location (which can only represent a single point) is being used across two road events (i.e the begin location for one road event and the end location of another road event). So a scenario like this could play out:

A similar situation also occurs with the traffic sensors where the individual lanes can be associated with road_event_id

Proposed changes

Discussion on whether this is the desired implementation of whether other methods could be identified. One possibility is to not include road_event_ids in the core details but require it for each device object based on how the device is used within the work zone.

Dunge commented 2 years ago

I agree it's a bit confusing. The term MarkedLocation also bring confusion because they aren't different locations. The coordinates are at the LocationMarker level. Each MarkedLocation in the same LocationMarker represent the exact same position, but is used to represent which type of element it is and on which RoadEvent they are linked to. Every LocationMarker can indeed be part of multiple RoadEvent. Either on an event split (end/beginning) as mentioned, or just for bidirectional roads (one event per direction).

I understand the concept of having a LocationMarker with two ids in the road_event_ids list in FieldDeviceCoreDetails, and two MarkedLocation, one for example being a road-event-end with one road_event_id and another being a road-event-start with another road_event_id. But if you ask me, for this situation I would prefer having a single road-event-split type and just the id list in the core details, not having to specify which one with multiple MarkedLocation. Every other types (lane closure, traffic light, etc.) can also be part of one or many RoadEvent, but simply having them listed in the core details road_event_ids list would be sufficient, I don't think having to duplicate them in a list pointing to each event individually bring any additional information.

So my proposition would be to completely drop the MarkedLocation object and just have a list of MarkedLocationType in the LocationMarker object instead, and keep using the road_event_ids in the core details as with every other devices. It would be simpler to produce and understand for consumers without really losing anything. But I'm probably missing some reasoning for this choice and curious to hear about Jacob intentions with this design.

As for the traffic sensors lane, I asked a similar question in #195 yesterday and the justification is to have a link to the lane definitions since they aren't part of the SwzDeviceFeed, and it make sense to have some kind of precision which lane represent which element in the other feed, which isn't possible with just the list in core details. But I would still vote to make it optional. I also have a few design question related to traffic sensor, especially those reporting both directions, the current object is not perfect to present that information, but this would be better placed in another issue.

j-d-b commented 2 years ago

@sknick-iastate I want to make sure I'm understanding the issue—let me know if this is a fair summary:

Issue summary

It is confusing that there are two properties for providing a road event ID for the LocationMarker device.

Initial comments

To start, the example scenario in your comment matches how the current design should be used. At the very least, I can clarify this by adding a feed example using the location marker for multiple positions.

As for your potential proposal of removing road_event_ids from the FieldDeviceCoreDetails, if I think it is valuable to have the ability to "link" any device to a road event, if desired. Thus I am hesitant to remove the road_event_ids property from the FieldDeviceCoreDetails. If it is too unclear/cluttered to have the event ID specified in multiple places, I'd lean towards removing it from the LocationMarker-specific properties if there is a way to do that without losing functionality.

So, this leads into what @Dunge proposed:

Potential solution

Pros

Cons

For example, say we have a LocationMarker with the following values:

One cannot know which road event it is the start of and which is it the end, without using the geometries and computation to determine where the events meet. With the current implementation, since a MarkedLocation can only have one road event ID, the relationship between the type (what it is marking) and the road event that applies to is explicit.

This may not be a significant issue, since the only case the road event ID specifically applies to the type is when the type is road-event-start or road-event-end.

Concluding question for discussion

sknick-iastate commented 2 years ago

Closing this issue. This was discussed at a previous SWZ Device sub group meeting. Including the road event in the marked location allows for defining the marked location type (which may be on multiple road events) which isn't feasible by using the road event in the core details without replicating the device multiple times.