Location verify method

[sknick-iastate]

This pull request addresses the issues identified in #129. Initial discussion focused on providing a list of enumerations for the location verify method but after further discussion it was determined that verified location information should be made using a GPS equipped device (i.e. not verified through cameras, site inspection, etc). It was determined that this would be better achieved by updating the SpatialVerification enumerations to clarify that a GPS equipped device is required for verification and depreciating the location_verify_method.

As further justification the location_verify_method is at the data source level and wouldn't allow for different verification types for individual road events. If this is a desired then another attribute should be added at the event level.

So in summary the changes are:

• Deprecate location_verify_method in the RoadEventDataSource
• Redefine the SpatialVerification enumerations to clarify that verified work zone locations should use a GPS enabled device

[j-d-b]

Thank you @sknick-iastate.

[j-d-b]

Alternatively, here's a different implementation of the same change that simplifies the specification without losing functionality (which is my goal—make WZDx easy to use and understand while still being powerful):

• Deprecate location_verify_method (same as in this PR)
• Remove the SpatialVerification enumerated type
• Remove the RoadEvent's beginning_accuracy and ending_accuracy (which use the SpatialVerification enumerated type)
• 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).

In addition to being simpler and requiring less documentation (the new WZDx user doesn't have to reference an enumerated type and see it only has two values), I think the 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 describing).

Also, it makes it more clear what the buisness 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

The only downside of this approach is if we wanted to add more options than just estimated and verified for describing the accuracy of the start/end, though there has not been any desire for that. I think if there is not desire and members can't think of other reasonable options for start/end accuracy, we should consider the approach proposed here with the boolean properties.

[j-d-b]

@sknick-iastate let me know what you think of my above approach.

[sknick-iastate]

@j-d-b sorry for the delayed response. I like your approach for changing the verification to a boolean. I'd like to get feedback at our next specification update meeting then can make the change.

[j-d-b]

See #199 (comment)

[j-d-b]

I moved my alternate approach to a new issue, #213. The implementation here looks good for v4.0.