-
Notifications
You must be signed in to change notification settings - Fork 62
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
Improve machine-usability of location_verify_method #129
Comments
Jacob,
I would be interested in know this as well.
What you are asking for 0.1cm or 1mm accurate GNSS is extreme survey grade GNSS and it usually requires a static GNSS receiver for many minutes. Did you really mean 0.1cm?
My belief is, this level of accuracy is not required at all. Honestly, I don’t believe 1mm accurate GNSS is usable for virtually anything.
I would be thrilled if we could hold the WZDx event reports at 1 meter accurate GNSS. 1m accurate GNSS can be easily achieved with moving machinery and some type of dual-band differential GNSS (PPP, RTX, PP-RTX, etc.).
We actually are at 1.8m accuracy in our GNSS for our Automated Driving vehicles. Using single band GNSS.
I think we have to ask, what does increased accuracy buy us? From 1 meter accuracy to something larger like 10+ meters, we can accurately define individual lanes on the road where the larger accuracy cannot. The limit would be 1.825 meter accuracy, above this you cannot correctly identify individual lanes (DOT spec’d 3.65m wide lane as a reference), below this you can identify lanes.
Going sub meter I don’t believe gives us any more usable information. Now, I think this would be fun to debate and get other’s inputs.
Thanks,
Dave
|
@davidcraig4300 the 0.1cm came from the example for a values of I was not intending to discuss the level of accuracy required or desired, just the ability for the producer to specify the level of accuracy of their feed with a distance unit rather than as part of a longer, string text field. |
This should align with any recommendations about location verification coming out of the Workers Present group. |
Adding those field would be beneficial for the data user to judge how they are going to handle the data.
So providing a source and an accuracy element would help. |
Resolved in #199. |
Currently,
location_verify_method
, on the road_event_data_source in v3.0, is a text field with a very general description:While there is an example included, there is too much flexibility in what ends up in the content of this field for it to be useful for machines. It seems, based on the example "Survey accurate GPS equipment accurate to 0.1 cm", that this is intended to be just a human-readable, text description of the method. However, there is valuable data (accuracy!) here which could be parsed by machines if structured differently.
I would like to hear from other data producers what they are using as a location_verify_method, as in the example there are two pieces of separate information:
GPS
0.1 cm
I think spatial accuracy especially would helpful to have as a number (units separate). This could instead be added alongside/instead of "estimated" or "verified" for start/end coords, as currently even "verified" doesn't given that much information, especially when
location_verify_method
is not provided (it is optional).Curious other's thoughts as it seems there is more information that could be added to the road_event_data_source to benefit machines.
The text was updated successfully, but these errors were encountered: