Documentation

What works without an internet connection

If DiPAgE is already installed on the device, the application can be opened and used for the actual documentation even without an internet connection. Forms can be filled in, existing records edited and new plant protection product records saved. Downloading or exporting existing records and creating PDF files are also in principle possible offline.

The installed app is therefore also suitable, for example, for work in places with weak or no mobile coverage. For the smoothest possible use, it is still advisable to open the application and its locally stored auxiliary data regularly while an internet connection exists.

What happens if the connection drops in the online version?

If DiPAgE has already been opened in the browser and the internet connection then drops, the loaded application generally remains usable. Information already entered is therefore not automatically lost. You can in principle continue the documentation and save it locally.

The difference from the installed app shows mainly at start-up: without internet, the website may not be reachable at all. Anyone who regularly uses DiPAgE in places without a reliable connection should therefore install the application beforehand.

Which functions need an internet connection

Some functions access current external data sources. These include in particular the search for plant protection products and indications, parts of the crop search, and map and online services. Certain plausibility checks can also depend on current information from external data sources.

Without internet, these functions are temporarily unavailable or only available to a limited extent. The actual local documentation is separate from this. As soon as a connection exists again, the online services can be used again.

Practical handling of offline situations

If you know that you will be working without internet for a longer time, it is advisable to create the objects you need and recurring partial data beforehand. Frequently used locations, crops and – where provided in DiPAgE – reusable entries can then be used on site without depending on an external search every time.

After a longer offline phase, DiPAgE should be opened again while a connection exists, so that locally stored auxiliary lists can be updated.

How DiPAgE works technically

Although DiPAgE is provided via the internet, the application itself runs locally in the browser of the device used. This applies both to the web version and to the installed Progressive Web App. The plant protection product records, partial data and local working states you create are stored in the local browser storage of the device.

This distinguishes DiPAgE from classic cloud applications, in which every entry is stored immediately on a central server. The Julius Kühn Institute has no access to the locally stored plant protection product records.

What data sovereignty means in DiPAgE

Users decide themselves on which device their records are kept and when they pass files on to other persons or bodies. There is no (partly) automatic transmission of the complete plant protection product records to the JKI, advisory services, authorities or other third parties.

This set-up strengthens data sovereignty, but at the same time means that there is no central body that can restore a lost local working state. Anyone who deletes their browser data, loses the device or has a technical defect can, without their own backup, also lose the locally stored DiPAgE data.

When data does leave the device

Certain functions need online services. When searching for a product, querying an indication or using map services, a technical request is sent to the service concerned. The information necessary for this specific request and, for technical reasons, also connection data such as the IP address are transmitted.

The locally stored complete plant protection product records are not automatically sent along with such requests. The actual record files are only passed on when the user creates an export themselves and then sends or otherwise provides this file.

Local browser storage: advantage and responsibility

DiPAgE uses the browser’s local storage. Normally the data is kept even after the browser is closed and after a device restart. It becomes problematic if browsers or company policies automatically delete website data on exit, if private or incognito mode is used, or if the user removes the website or browser data themselves.

An installed web app, too, remains technically tied to the storage technology of the underlying browser or operating system. Installation alone therefore does not replace a data backup.

Back up regularly

The user or the farm is itself responsible for the long-term retention of the documentation data. It is advisable to export finished plant protection product records regularly as files and, in addition, to create a complete backup of the current DiPAgE working state at sensible intervals.

A complete backup is particularly worthwhile before major changes to the device, before changing the browser, before system or browser updates, before resetting a device, and whenever a larger number of new records has been entered.

Deliberately deleting local data

Anyone who wants to remove DiPAgE data completely from the device can delete the stored website data of the DiPAgE address in the browser. Beforehand, all records and backups that are still needed should be saved externally, because deleting the local storage cannot be undone.

Distinguishing a complete backup from a record export

A complete backup serves to back up the current working state of DiPAgE as completely as possible. Besides finished plant protection product records, this can also include partial data and other working information. Exporting individual protocols, by contrast, serves mainly to file specific plant protection product records permanently, to pass them on, or to import them again on another device.

For the ongoing archiving of finished records, the protocol export is particularly suitable. A complete backup is additionally worthwhile if the complete working state of the application is to be preserved or transferred.

Creating a complete backup

In the “Profile” or “Data management” area, a complete backup of the current DiPAgE working state can be downloaded. This backup file should be stored in a reliable place, for example in the farm’s file storage, on an external storage medium or in a cloud storage approved by the farm.

A backup file is especially valuable if a device has to be replaced or the local browser state is lost. It complements the export of finished protocols, but does not necessarily replace orderly archiving of the individual plant protection product records.

Restoring a complete backup

A complete backup can be restored in DiPAgE in order to recover an earlier working state or to transfer a complete working state to another device. Note that restoring a complete backup replaces the existing working state on the target device.

Before restoring a backup on a device that is already in use, the current working state there should therefore be backed up first as well. That way you can return to that state if in doubt.

Importing individual plant protection product records

In the “Protocols” area, exported plant protection product records can be read in again. The machine-readable file formats provided by DiPAgE are supported, in particular JSON, XML and CSV; bundled files can also be imported, depending on the export form.

The import is suitable, for example, for transferring records between two devices, for taking over records from a shared file storage, or for checking records provided by another person.

Incomplete records during import

If an imported record does not contain all required details, DiPAgE can point out the missing information. Such records can be accepted for further editing and marked as incomplete. The missing mandatory details must be added before a legally compliant export.

DiPAgE can thus also serve as a checking and post-processing environment for data that was not created completely in the application itself.

What happens in the event of conflicts?

If, during import, a record meets an existing record with the same identity but different content, DiPAgE shows a conflict resolution window. The local and the imported version are shown side by side there. Differing properties are highlighted, so that you can see where the two versions differ.

You can then decide which version is to be kept. This avoids a differing file overwriting an existing record unnoticed. For larger imports, conflicts should be checked deliberately and only then saved.

Telling location, object and treated object apart

The treatment location describes where a plant protection measure takes place. This includes the geographic or administrative location and the size or extent of the location. In DiPAgE, this location is managed together with the respective crop and cultivation context as a reusable object.

The “treated object”, by contrast, describes the portion of the measure that was actually treated. An object can, for example, be a 10 ha field, while in a specific application only 4 ha are treated. The object then stays 10 ha in size; the treated object of this individual measure comprises 4 ha.

How an object is delimited

As a rule, an object is a contiguous area of the same crop species or – if the conditions are met – the same crop group. In agricultural crops, the sub-field (Teilschlag) is the smallest common observation unit. Different varieties of the same crop species do not, in themselves, lead to separate objects.

For reuse in DiPAgE, the associated year also plays a role alongside location and crop. An object should therefore be created anew for a new crop or application year. Existing details can be used as a starting point and saved with a changed year as a new partial record.

Which location reference is used

DiPAgE supports different kinds of location referencing, including coordinates, cadastral parcel identifiers (Flurstückskennzeichen), InVeKoS references, area geometries, and special reference options for railway tracks, forestry areas and paths. Depending on the reference chosen, the details required for it are requested.

If an InVeKoS reference from an area application exists for a treated area, it is in principle to be used with priority. In Germany the referencing is done via the FLIK. Depending on the federal state, additional details such as field or sub-field number may be required for unambiguous assignment. If there is no InVeKoS reference, the other forms of georeferencing provided for in the data standard can be used.

Several location references for the same object

Several location references can be stored for the same object if needed. This can be useful, for example, if a FLIK is not yet available at the time of documentation and another reference, such as coordinates, is used first. The FLIK can be added later.

It is important that several references always describe the same object in different ways. The function is not intended to combine several separate locations in a single object.

InVeKoS map function

For suitable location references, DiPAgE supports input via a map view. Coordinates or areas can be selected spatially this way, instead of entering all details completely by hand.

Official InVeKoS objects including their area geometries are currently only available in the DiPAgE map for North Rhine-Westphalia. Areas in other federal states can therefore currently not be selected from the map as InVeKoS objects in the same way. The location data can nevertheless be documented there via the input options provided.

Saving and reusing objects

Frequently used locations or objects can be saved as partial data. The same location and crop information then does not have to be entered completely again for every plant protection product application. This is particularly helpful for regularly treated fields, installations or farm areas.

When changes are made, you should check whether the same object is still being described or whether a new object has to be created – for example for a new year or a changed crop.

The Object Manager as the control center

The Object Manager brings together the saved objects and their most recent plant protection product applications. From there, objects can be selected, combined for multiple applications, and existing protocols opened specifically.

The Object Manager is also a particularly safe way to jump to a specific plant protection product record in the “Protocols” area. This is helpful, for example, if a record is to be edited or deleted, or if an existing application is used as a template for a new record.

How the product search works

The product search is unlocked after a crop has been selected. While typing, you can search by product names or authorization numbers. The actual product and indication search accesses a current online data source and therefore needs an internet connection.

The search is embedded in the normal documentation flow: first the crop is determined, then suitable product suggestions are offered. This means you do not have to search in a completely unfiltered product list.

Crop-first principle and search results

DiPAgE distinguishes between products that are authorized for the selected crop or crop group, and other plant protection products that are authorized in principle. The latter can be relevant, for example, if a farm holds a special authorization for use.

Selecting a generally authorized product is not proof that the specific application is legally permissible. Whether a required individual farm authorization or other basis actually exists must be ensured by the user.

Parallel imports

Parallel imports can be documented directly in DiPAgE. In the result list, the associated parallel imports are shown alongside regular reference products and can be selected. For the documentation, the corresponding designation including the required authorization number is taken into account.

Parallel imports therefore do not have to be recorded under a freely invented product name, but can be taken over in a structured way from the intended product selection.

Emergency authorizations

There is a separate search for emergency authorizations. When entering the plant protection product, the “Emergency authorizations” option can be activated. DiPAgE then searches not in the normal product list but in the stored information on emergency authorizations.

Emergency authorizations under Article 53 of Regulation (EC) No 1107/2009 can carry designations that differ from regular authorizations; in particular, an ordinary authorization number is not available in every case. DiPAgE takes this special feature into account in the documentation.

Expired and historical plant protection products

Expired or historical plant protection products can also be relevant for retroactive documentation. Such products therefore remain findable in the search. DiPAgE can indicate that a product is no longer currently authorized and show the associated authorization period and any existing sell-off and use-up periods.

Indications and additional product information

Additional information on the specific indication can be selected for a product. This information helps DiPAgE, for example, to recognize whether a BBCH stage is necessary.

Crop species or crop group

As a rule, the specific crop species is to be documented with the associated BVL-EPPO information. An overarching crop group can be permissible in particular in ornamental plant and vegetable production, in nurseries, in forestry and in the home and allotment garden sector.

The prerequisite is that the plant protection product used is authorized for this crop group and, in addition, either there is no separate authorization for the specific crop species or several crop species of the same crop group are grown or treated at the same place of application. A crop group is therefore not a general substitute for a specific crop species.

Different varieties

Different varieties of the same crop species do not lead to several objects. What matters is the crop species or – in the cases provided for – the crop group. A contiguous vineyard or orchard area can therefore form a common object despite different varieties, as long as it is not interrupted by relevant structural elements or open areas.

Succession cropping

In succession cropping, the (sub-)field of the respective crop remains the overarching object. The individual batches are understood as sub-areas or treated sub-objects and do not each have to be georeferenced separately or created as their own object.

The batch actually treated can be documented via the size of the treated object and, if needed, additionally designated in the description field, for example as “Iceberg lettuce batch 2”.

Migratory and rotational cultivation

There is a simplification for certain migratory or rotational cultivation systems. This applies in particular to ornamental plant production including nurseries and to vegetable production, where crops or crop groups are grown on changing areas within a year during their production period, for example with batch changes or multiple use of the same area.

In these cases the geolocation and area specification can be based on the production site (Betriebsstätte). The production site is then the smallest unit to be considered, so that not every area that is used alternately has to be georeferenced separately.

Dressings of seed and planting material

DiPAgE is not limited to classic area treatments. “Beizung” (dressing) can also be chosen as the type of use; a distinction can then be made between seed treatment and planting material treatment.

For dressings, not the treated area but the treated quantity is documented, for example in grams, kilograms, decitonnes or tonnes. For seed or planting material treatments, no division into overarching object and treated sub-object is provided, because this separation is not practical for this type of application.

Applications in rooms and greenhouses

Besides outdoor applications and dressings, applications in closed rooms can also be documented. Depending on the context of use, this includes, for example, stores, greenhouses and other interior spaces. The type of use controls which follow-up details DiPAgE asks for and whether an area, a volume or a quantity is specified as the treated object.

Treating several objects together

Multi-select mode can be activated in the Object Manager. Several compatible objects can then be selected and given the same plant protection product application together. The prerequisite for this is currently that the selected objects have the same crop species or the same crop group permitted for this.

Multi-selection is an input aid. In the background, a separate plant protection product record is still created for each selected object. This keeps every single application assigned to a specific object.

Recording tank mixes

In the application form, tank mix mode can be activated after the first plant protection product. Further plant protection products can then be added. For each product, the product-specific details, in particular the application rate actually used, are recorded separately.

A tank mix does not lead to a single common record. If, for example, two products are applied on the same object, two independent plant protection product records are created with the same treatment location, but each with its own plant protection product and its own application rate.

Saving frequently used tank mixes

Recurring combinations can be saved as partial data and used again later. Depending on how you work, the entire tank mix or individual plant protection products can be stored as reusable partial data. Tank mixes can thus be prepared without having to select every product completely anew for each application.

Combining multi-selection and tank mix

Both functions can in principle be combined: a tank mix can be applied to several compatible objects. The record logic is preserved in the process. For each selected object and each plant protection product used, an independent plant protection product application record is created.

This separation is important because each product must remain individually traceable, even if in practice the application took place in a single pass.

Finding and filtering protocols

The saved plant protection product records are managed in the “Protocols” area. There, individual records can be searched directly or narrowed down using filters, for example by crop, plant protection product, location or year.

If the record you are looking for belongs to a known object, the route via the Object Manager is often simpler: there the most recent applications of the object can be expanded and then opened directly in the protocols area.

Editing a plant protection product application

In the “Protocols” area, select the record concerned and open it via the edit function. You can then adjust the details you want and save again.

Editing makes sense if there is an error in an already saved record. It should not be confused with the “Use as template” function: when editing, the existing record is changed; with a template, the old record remains unchanged.

Deleting an incorrect record

A single plant protection product record can be deleted in the “Protocols” area. To avoid accidental deletions, the record should first be identified clearly via search, filters or the direct jump from the Object Manager.

Especially with many similar applications, the route via the specific object in the Object Manager is recommended, so that the right record is actually opened and removed.

Using an existing record as a template

In the Object Manager, an existing plant protection product application can be expanded and, via “Use as template”, taken over as the basis for a new record. The original record remains unchanged in the process.

This function is suitable for recurring applications in which many details are the same or similar. Before saving the new application, you should in particular check the date, year, application rate, treated object and all product- or indication-dependent details.

Preparing spray sheets and work orders

A plant protection product application can be prepared before it is actually carried out. The planned details can then be output as an easily readable PDF and, for example, printed or passed on digitally to the person carrying out the work.

In this way DiPAgE can be used as the basis for a spray sheet or work order. After the actual application, the record should be reviewed and, where necessary, adjusted to the application as actually carried out.

Available export formats

DiPAgE supports exporting plant protection product records as JSON, XML, CSV and PDF. JSON, XML and CSV are text-based, machine-readable formats and are intended for structured electronic processing. A prerequisite for legally compliant documentation is that the required details are contained completely and in accordance with the specified data standard.

PDF, by contrast, serves the readable presentation for humans. It is suitable for your own filing, for review, as a spray sheet or for showing at an inspection, but is not the intended machine-readable documentation format.

Why XLSX is treated differently

JSON, XML and CSV are text-based file formats. Their contents exist directly as text and can be read out in a structured way by software on the basis of a defined syntax or defined separators. They can therefore be read in as text without a format-specific office application and processed automatically.

XLSX, by contrast, is not a pure text format but a ZIP-based container format in which several XML files and other components are combined into an Excel workbook. XLSX files can also be processed automatically, but this requires software that interprets the structure of this file format. They are therefore not as easily machine-readable as simple text files like JSON, XML or CSV. In the DiPAgE context, XLSX is therefore not used as a machine-readable exchange format within the meaning of the data standard applied.

Exporting single or several protocols

In the “Protocols” area, individual plant protection product records can be selected and exported specifically. Alternatively, the existing records can be narrowed down using filters, for example by crop, plant protection product, location or year.

The filtered records can then be output as individual files or – depending on the format chosen – bundled in one common file. Without filtering, all existing plant protection product records of a farm can also be exported together this way.

Transferring data to another device

There is no automatic synchronization between several devices. To transfer records, they are exported on the first device, brought to the second device by a suitable transfer route, and imported there again.

The transport can take place, for example, via USB stick, email or a cloud storage. DiPAgE itself does not provide its own cloud storage; the choice of transfer route is up to the user or the farm.

Shared cloud storage as a manual exchange route

A shared cloud folder can simplify data exchange between several devices or persons. It does not, however, replace true live synchronization. The files still have to be deliberately exported from DiPAgE and imported on the other device.

This manual process prevents local working states from being overwritten unnoticed by a central cloud version. At the same time, a clear rule within the farm is sensible on which file counts as the current state and who makes changes.

Passing records on to advisers or authorities

If plant protection product records are to be passed on to an adviser, inspection body or authority, the user exports the required records in the desired format and transmits the file themselves. DiPAgE does not send the saved protocols to third parties automatically.

For machine exchange, the intended structured formats should be used. For a purely visual check, a PDF can additionally be helpful.

Use during on-site inspections

DiPAgE can also be used to view and check existing records. Files provided by the farm that comply with the data standard can be imported into the “Protocols” area, viewed individually there and, if needed, output as an easily readable PDF.

Filter functions make targeted selection easier, for example by plant protection product, crop, location or year. DiPAgE can thus be used both on the side of the documenting farm and as a tool for the structured viewing of existing files.