We have a 1-to-many relationship between fields and boundaries. However, each field always has one active boundary, defining its spatial footprint at a time, which must not overlap with any other field’s active boundary.

The Global FieldID product allows any number of boundaries to be registered, and thus any point on the map might have multiple boundaries representing specific operations.

The boundary of a field can change over time, but the history is retained using a link between the field and boundary, each of which has a timestamp. Any ‘old’ boundary is retained. This helps application developers to maintain an up-to-date view as boundaries change.

The Global FieldID product tackles changes over time by decoupling the concept of the field and its boundaries and storing history.  

There are two types of changes: 

Changes to the boundary that don’t turn it into a different field. 

• The old boundary ID is ‘deactivated’ (not deleted) and a new boundary is linked in its place (the date of the change is recorded). The field ID doesn’t change. 
• Since the old boundary still exists with its own ID, use cases that depend on identifying a specific boundary are not impacted but are able to understand that the field itself has since changed. 

Changes to the boundary that turn it into a different field (e.g., splits, merges, and farmland development).

• It is possible to ‘deactivate’ one or more field IDs and replace them with new fields, each of which has its own boundary (e.g., when a tree line is removed to create a larger single crop area, one new field ID can be created to replace the previous two).
• All applications integrating the Global FieldID product will be able to trace these events and access the history. 

A crop zone is identified as a boundary within the Global Field ID product (GFID). A boundary ID can be used to identify a specific area of land within the field because GFID also allows the registration of multiple boundaries.  

Yes. Alongside the primary boundary used to define the location of a field, there can be other types of boundaries, each used for a specific purpose. Even if there is a region within the field, spanning multiple fields or a region that is not part of any field, it can be identified with a boundary ID. 

We will soon introduce the ability for API client applications to register such boundaries on behalf of their users.  

The Global FieldID product aims to have a complete set of boundaries for each country it covers. 

We currently have coverage of the UK, France, and the Netherlands, and we are planning a rollout in the Americas during 2023 (starting with Brazil and the US). We expect smallholder geographies in Asia and Africa to be added in 2024.  

However, we will soon introduce the capability for users of the GFID product to create field IDs by submitting boundaries from anywhere in the world, even without having done the rollout for that country. 

The Global FieldID API only collects metadata about the field itself and does not hold any type of data (e.g., data about farmers’ practices). 

We believe that GFID should be an enabler for all, and not compete with existing data providers or farm management applications. It aims to be a “universal language” that ensures data exchange between applications and data discovery throughout the supply chain​.  

There are two main types of identifiers in the Global FieldID product: 

1. The Global FieldID, designed to be reliably communicated in both digital and non-digital channels. It is a short sequence of characters, like this: 15KW.V5JZ  

1. The Global BoundaryID is designed for software data exchange, and is a UUID, like this: 2bbc9443-7b65-4a9c-806b-78d20298ab4b 

Further technical information is available on our Developer Portal.