search

ADAPT / Standard

ADAPT Standard data model issue management
https://adaptstandard.org
MIT License
6 stars 0 forks source link

Review Field Boundary GNSS Quality Information #145

Open knelson-farmbeltnorth opened 1 month ago

knelson-farmbeltnorth commented 1 month ago

@crakerb-ship-it and the Field Boundary GNSS Working group have prepared the attached. We should review vs. the current state of Field Boundary (https://adaptstandard.org/docs/field-boundary/) and GNSSSource (https://adaptstandard.org/docs/gnss-source/)

Initial Field Boundary GNSS Attributes.pdf

knelson-farmbeltnorth commented 1 month ago

My initial feedback is that since ease of/consistent of data consumption if primary in ADAPT, boundaries must be in WGS84 in line with all other geometry data in the model.

I'm wondering what the value is in tracking a source coordinate system if something other than WGS84. Is it simply to flag the boundary as data with a higher probability for error? This departs from the philosophy we've used to date that ADAPT records data that is accurate to the best of the data producer's ability, and should it be found otherwise, the consumer works with the producer to fix it. As I recall, we had such an attribute in the ADAPT Framework and removed it here for these reasons.

Also, boundary offset from the receiver is no different than the implement widths and offsets we've suppressed in the Standard. The geometry must record where the boundary is, not where the receiver was.

crakerb-ship-it commented 1 month ago

The rest of the team can chime in too, but I think what you suggest with regard to ADAPT is accurate. The list the WG put together was based on what someone receiving a boundary would want to know to make an informed decision on if it was captured with a sufficient level of accuracy for their purposes. The idea being the needs of an autonomous vehicle are likely different than someone clipping a background soil type map. WGS84 makes sense to align with the rest of ADAPT, the reason we had for including was just to know if was different so it could be handled/converted properly. But in the context of a transfer format like ADAPT I agree it would make sense to specify what will be used and not leave it open to interpretation.

Some of the finer points about GNSS source will likely be the part to discuss in greater detail. We had a lot of discussion about knowing what correction source, down to the base station ID was used during definition. The goal being to ensure when a boundary goes from one system to another its true location on the ground stays the same regardless of correction source the machine is using, assuming they are of comparable accuracy.

knelson-farmbeltnorth commented 1 month ago

Per discussion in the 22 May 2024 meeting, we will remove GNSSSource from the beta schema at this time with goal of coming back to it and implementing it more fully and correctly.

Andreasox commented 1 month ago

Just to ensure that you understand that WGS84 do have an accuracy cost, varying over the globe according to local gravity. To my knowledge the accuracy cost is not important for operative agriculture.

Hälsningar

Andreas Oxenstierna Dalen Hörbyvägen 53 243 94 Höör 0730-26 97 12 On 22 May 2024, 17:51 +0200, Kelly Nelson @.***>, wrote:

Per discussion in the 22 May 2024 meeting, we will remove GNSSSource from the beta schema at this time with goal of coming back to it and implementing it more fully and correctly. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

knelson-farmbeltnorth commented 3 weeks ago

@Andreasox Yes, we discussed the issues with using WGS84 globally. It was also our collective experience that any accuracy issues are not substantive for ADAPT's use cases.