fiboa / specification

Field Boundaries for Agriculture (fiboa) - a specification that describes important properties of field boundaries
Apache License 2.0
9 stars 2 forks source link

More details on determination method #31

Open cholmes opened 2 months ago

cholmes commented 2 months ago

I'm not clear enough on the distinctions of the different determination methods. It'd be good to have more detailed descriptions about what each is and how to determine between different options. Like if I get field boundaries from the government does that mean they're adminstrative? What if they were also surveyed?

m-mohr commented 2 months ago

@andyjenkinson What was the source for this again? Thanks.

andyjenkinson commented 1 month ago

Hi, trying to get an accessible link that doesn't require you to be an AgGateway member, but it's based on the work of Working Group 17 - Field Boundary use cases & definitions, whose members produced some controlled vocabularies, examples and list of potential use cases. The first and most obvious overlap I saw there was the metadata term used to indicate how the boundary is generated, so I lifted the vocabulary terms from there.

In the meantime, here is Ben Craker's explanation of the terms for what the WG called "Boundary Creation Method", which IMO is semantically the same as FIBOA's determinationMethod:

  • Manual (hand drawn from imagery) i.e. using tool in FMIS to point and click on a map
  • Driven:
    • This can also be split into what level of GNSS accuracy the machine used during boundary creation.
    • GNSS Quality: Sub -meter, -decimeter, -centimeter
    • Also depending on the level of detail things like if it had an IMU engaged to compensate for roll/pitch/yaw in addition to the mounting location on the machine to know how high the receiver was off the ground...
  • Surveyed
  • Administrative (CLU) - this just means it is defined by some other authority and is likely one of the other methods but likely no knowledge of what exactly
  • Unknown
  • Auto-created from operation - similar to driven, however this is using the coverage map to determine the boundary, whereas "Driven" the operator actively selected in the terminal to create a boundary [aj: so for example, a boundary derived from what the industry would describe as an 'as-applied map': one can infer the boundary of a field, using the area that the machine drove whilst it was spraying the field'. whereas a 'driven' boundary would be done by explicitly driving around the edge and maybe around obstacles with the specific intention to map it]
  • Auto-created from imagery

One key issue for me (and this is true actually for quite a few of the metadata fields in FIBOA) is to what extent they are mutually exclusive. For example, if a boundary was predicted from an image but then confirmed by a human as being accurate.

Particularly here for an 'administrative' boundary, IMO this is more a reflection of the provenance of a boundary than it is a method of generating it. The issue is that quite often that method is opaque, but yet can be very high quality so it's very unsatisfactory to just say 'unknown'. For example the French RPG - it's considered to be "ground truth" and generally high accuracy because of what it is used for - i.e. paying subsidies, but what method of determination would you use for those boundaries? For example, these government data systems do tend to use some form of manual verification to check boundaries, even if they used earth observation to initially generate the map or detect changes that are sent for manual review. When the data is published they just publish it as one dataset with no information about how exactly each boundary was determined (and in some cases it could be a mix so this info is lost). This is one reason why in GFID we surface most of these metadata terms as independent 'references' - there can be multiple opinions published about a geometry by different datasets, and might not be consensus. Therefore a lot of these terms end up being arrays, not scalar values.

Worth noting that the AgGateway WG has a fair amount of potential source material for metadata associated with a field boundary. The GNSS accuracy is mentioned above (could be an extension) but lots of others, as well as a good list of use cases. Hence why I want to get it accessible to this community. There are also other working groups related to field boundaries.

Worth bearing in mind that AgGateway's members tend to be those who deal with on-farm data in the 'real world' within the farm gate, like Agri-Techs facing interoperability challenges, rather than more abstract or academic 'analytics' use cases for large scale datasets that the 'geospatial community' is sometimes oriented towards. These systems are where the vast majority of existing field boundaries today are actually stored and they understand a lot of use cases for them.

andyjenkinson commented 1 month ago

By the way, the intention for AgGateway would be to get these definitions into the ADAPT Standard.

cholmes commented 1 month ago

Thanks for all the great info @andyjenkinson!

Will respond in full soon, but wanted to comment on one thing:

Particularly here for an 'administrative' boundary, IMO this is more a reflection of the provenance of a boundary than it is a method of generating it.

I had been wondering about that myself - indeed I think it was part of why I was wondering how these worked. I do wonder if it'd be better to have some subset that is really 'mutually exclusive' - force picking one of them. But then have another attribute that is more about 'ground truth'. Like in an ideal future world where fiboa is everywhere the french government would include determination method in their data, and then we'd also have a way to designate that some datasets are 'official' in some meaningful way.