Refactor RoadEvent beginning and ending accuracy

[j-d-b]

This issue is regarding refactoring the beginning_accuracy and ending_accuracy properties on the RoadEvent for clarity.

I originally proposed this idea in https://github.com/usdot-jpo-ode/wzdx/pull/199#issuecomment-907206410 and moved it to and issue as it is separate enough from #199 to be discussed separately.

The proposed changes simplify the specification without losing functionality (which is my goal—make WZDx easy to use and understand while still being powerful).

Proposed Changes

• Deprecate location_verify_method (which is proposed in #199)
• Remove the SpatialVerification enumerated type
• Remove the beginning_accuracy and ending_accuracy properties (which use the SpatialVerification enumerated type) from the RoadEvent object.
• Add new properties is_begin_location_verified and is_end_location_verified to the RoadEvent which have boolean values indicating whether or not the begin/end is verified (if it's not verified, it's estimated, so we don't need an enumerated type if there are only two options).

Pros

• Simpler and requiring less documentation (the new WZDx user doesn't have to reference an enumerated type and see it only has two values)
• The name is_begin_location_verified is more clear what the property is describing than beginning_accuracy, which doesn't indicate by name that it's for the location (we could name it is_start_point_verified to be more clear, because that's what the property is specifically describing).
• Makes it more clear what the business rule for the use of is_begin_location_verified could be:

is_begin_location_verified and is_end_location_verified must only be true when the location is based on actual reported data from a GPS equipped device showing the measured location of the work zone

Cons

• If we wanted to add more options than just estimated and verified for describing the accuracy of the start/end
• Breaking change with no functional value.

[j-d-b]

The fact this is a breaking change and just "cleanup" almost led me to not post this issue. However I thought it should be recorded for when there is a time where we are making breaking changes and/or other changes that may affect this property/concept. Then, it could be a good thing to implement.

[natedeshmukhtowery]

Thanks for recording this for future discussion. I think the proposal is logical, but I would definitely like to hear from other state and local agencies working to produce WZDx feeds for their thoughts both on the proposed approach as well as on implementation. Thanks!

[j-d-b]

There were no additional options for accuracy brought up at the Spec Update Subgroup meeting, so we can move forward with the boolean refactor.

[j-d-b]

Resolved in #281.