Recent Features

We are continuously improving the system; here are some recently introduced enhancements.

Self service developer registration and organisation management

We have now made it possible for individual developers and organisation to register and create application credentials directly through a self-service account management tool, enabling them to start using the API immediately.

Pre-prepared bulk downloads

We have now made available monthy exports of current field boundaries (i.e., the primary active boundary of each field in the system). These are broken down by country and published in our download hub.

Creating and updating FieldIDs

The first phase of the FieldID system exposed IDs for fields managed by Varda from, using a combination of public data (where available) and earth observation to delineate fields in specific countries. This enabled agri-tech applications to 'lookup' a canonical ID for fields they already hold, as well as enable growers to import fields.

However, the FieldID system also allows third-party applications to create and update fields on behalf of their users, transforming the FieldID system into a read-write open ledger so that growers can obtain a FieldID for all of their fields no matter where they are, and participate in ensuring their fields are accurately represented in the system.

The system allows fields to be:

created
updated (one boundary replaced with a new boundary, retaining the same FieldID)
retired
merged (two or more fields replaced by one field)
split (one field replaced by two or more fields)

Some of this functionality is demonstrated in our standalone free user interface.

Note that write access to the API is made available on request; in particular creating fields should only be done in specific scenarios to ensure data quality is maintained. Please contact us if you believe your application can help growers and advisors to claim their fields and actively participate in updating the map.

Boundary registry

In addition to updating and creating field boundaries, we also expose the capability to register alternative boundaries representing any arbitrary area of land related to the field, without changing the definition of the field itself. This is useful when it is necessary to obtain a common Global BoundaryID for a specific area of land that should not change.

Examples include:

a subset of a field used for a field trial or regenerative agriculture agreement
the specific boundary generated by a planting or application operation, that may cover only part of or more than one field
a farm boundary
an alternative dataset of field boundaries, to enable linking to third party IDs

Whereas a FieldIDs is intended to uniquely identify a field consistently for all users and therefore requires a public boundary that does not overlap with another field, a boundary:

Can be any shape, size and location - the only restriction is that it must be syntactically valid.
Can be kept private, with access to the geometry and metadata by other users managed via permissions.

Boundary references

A major aim of the Global FieldID system is to deduplicate fields and boundaries across multiple systems and users by providing a globally unique common identifier, along with a geometry. A BoundaryID deduplicates references from multiple systems/users to the same area of land. However, sometimes a use case requires to work with one specific instance of a boundary, according to the application that registered it. Each time the 'same' boundary is registered, we identify each instance separately as a boundary reference.

We now expose these objects in the API, including the source-specific metadata and any 'local' identifier. This allows the service to be used as a cross-referencing system, to map back and forth between existing global and local identifiers, such as those issued by national governments or software platforms.