Missing important values for MarkedLocationType enumeration

[dxpack]

Issue name: “Missing important values for MarkedLocationType enumeration”

Summary

Location markers in a work zone (or road event) may not be exclusive to the start or end positions, or may be indeterminate in terms of order within a series of location markers. Currently the MarkedLocationType enumeration only supports "start" and "end" locations for road events or work zones. This precludes using marked location devices that are either intermediate to those positions or indeterminate of delineation. Within the WZDxFeed, the preferred method of delineating a work zone is via more than 2 points, which necessitates an intermediate to the start and end positions. Currently the SwzDeviceFeed will not support the inclusion of that 3rd, intermediate, marker device because the MarkedLocationType enumeration does not have an option for it.

Motivation

Adding this as an issue so it doesn't get lost as an existing PR

Proposed changes

Detailed in PR #227

[Dunge]

Reference: MarkedLocationType

I agree with the suggestion of having a supplementary value for positions that are known as part of the work zone and not part of the listed supported device types. Personally I would call it waypoint or just other, but the suggested -intermediate value can work too.

I'm less confident in with the PR suggestion of differentiating between road-event-intermediate and work-zone-intermediate, since both are in the middle. It make sense to delimit the boundaries of the individual events in a bigger work zone, but not the middle points, since they are all middle to both the event AND the work zone.

As for the suggested -undetermined value, I understand they are to represent moving equipment that can be in or outside the work zone. I believe these should be completely absent if they are out of the bounding box or too far away from the events, but I don't see any harm at having the value available. We should make sure to have a clear description as to when this value to be used.

I would also suggest to add the value worker. Just like the flagger value, to pinpoint worker presence that are not necessarily waving a flag.

And I know it's important not to go outside of the scope of work zones, but I could also see value in added aluminum signs as new types. It could go as far as having the specific MUTCD code for temporary work zone signage.

[dxpack]

The MarkedLocationType enumeration currently has:

road-event-start road-event-end work-zone-start work-zone-end

The PR addition of

road-event-intermediate work-zone-intermediate

is intended to correspond to the existing enumeration structure where road-events and work-zones are 2 different categories.

The -undertermined addition, as noted in the PR, is for allowing devices to be grouped with road-events / work-zones that are GPS marked but not for the purpose of describing the shape/path of the road event / work zone. The examples provided include moving devices and fixed position devices ahead of / behind the precise manifestation of the road event or work zone (such as a static message board to notify oncoming traffic to an approaching work zone). These types of devices are categorically a part of the road event / work zone, but are not descriptive of the bounds of the road event / work zone.

[j-d-b]

I want to expand this issue to discuss other options for things to add to the MarkedLocationType enumerated type, based on SWZ Subgroup discussions so far and desires from members and co-chairs:

• delineator: a generic delineation point in a work zone. This could be used in place of all the intermediate options proposed above and is more general to be used for most types of marked locatins that don't fit into the other categories. However, it may be too general and thus not provide much value.
• ramp-closure: the point where a ramp is closed due to the work zone. Potentially, the existing type lane-closure could be used for this. We need more information from consumers to know the critical distinction between a lane and a ramp; as WZDx LaneType considers ramps to be types of lanes, there may be no difference and we should not add this value.

[j-d-b]

Expanding this issue to discuss all types of enhancements to the MarkedLocationType, after discussion between co-chairs of the WZDx Workers Presence and Smart Work Zones Subgroup, it was decided that we should propose adding functionality to use the LocationMarker to represent wearable devices, such as connected vests. Thus, proposed for inclusion is the following enumerated type value:

• wearable: a connected device that is worn by a worker in a work zone.

[sergebeaudry]

I agree with @j-d-b in regards to the wearable value for the MarkedLocationType (link)
We already had the flagger value, the new wearablewill cover many others cases.

[j-d-b]

Updates:

• "wearable" has been implemented in #293 as personal-device.
• "delineator" covers all the "intermediate" options proposed in #227; #227 can be closed and a new PR adding delineator will be created.
• "lane-closure" could be used for ramp closures, since ramps have lanes and can be represented in WZDx road events as lanes, but based as the LocationMarker covers various use-cases it is easier for current users to have ramp-closure as a separate MarkedLocationType. Similarly, road-closure can be added to allow using a LocationMarker to represent when an entire road is closed. As we are in the early stages of the DeviceFeed and especially LocationMarker, having explicit a MarkedLocationType for each common scenario we know that current feed users want to use a LocationMarker for is reasonable—we can simplify or refactor in the future based on experience.

[j-d-b]

Resolved in #293, #311, #312.