Link agronomicCropCategory with a botanical species

[AFoletti]

digiFLUX would like to see an easy way to limit the available choices of botanical species according to the agronomicCropCategory user choice.

Example:
The user picks "Winterweizen" as agronomicCropCategory --> the botanical species multiple choice is limited to the species which are allowed for this CropCategory.

Currently, agronomicCropCategory (see

eCH-0265/src/eCH-0265-1-0.xsd

Line 427 in 4b5d9be

<xs:complexType name="agronomicCropCategoryType">

) is an enumeratedType. The link between the CropCategory and the botanical species is done thanks to the botanicalPlantType complex type. See:
https://github.com/blw-ofag-ufag/eCH-0265/blob/4b5d9be03984dcf3ec2024519458119a873086de/src/eCH-0265-1-0.xsd#L350C24-L350C42
and

eCH-0265/src/eCH-0265-1-0.xsd

Line 395 in 4b5d9be

<xs:element name="agronomicCropCategory" type="eCH-0265:agronomicCropCategoryType">

Since the botanical plants are meant to be taken from the EPPO database, I think we should rework the whole.

• botanicalPlantType should simply be a reference to an EPPO code. We should not publish a codelist for that, since the master will be EPPO.
• agronomicCropCategory should be expanded from a "simple" enumeratedType to a complexType including not only a code and description but also a list of valid EPPO codes. The list of valid EPPO codes for each agronomicCropCategory must be delivered by subject matter experts.

Other miscellaneous info:

• The agronomicCropCategory are the GRUD crop categories. We should understand where the authority is and initiate the mapping to EPPO codes.
• It is possible that directPaymentCropType (https://github.com/blw-ofag-ufag/eCH-0265/blob/4b5d9be03984dcf3ec2024519458119a873086de/src/eCH-0265-1-0.xsd#L444C24-L444C45) is in a similar situation. It is, however, already a complexType and not an enumeration. This type is linked to a variety instead of a botanical species. We should check if this link makes sense or should rather be handled the same way as for the agronomicCropCategory.
• digiFLUX would like to see this changes (better link of agronomicCropCategory with a botanical species) by the end of September 2025

@hurni your thoughs on that?

[hurni]

Mapping botanical species and agronomicCropCategory should be feasible and also helpful for others than digiFLUX. This would have to be an n:n-relation as far as I know.

Example: The user picks "Winterweizen" as agronomicCropCategory --> the botanical species multiple choice is limited to the species which are allowed for this CropCategory.

Should Implementations such as filtering/multiple choice really be done by a the standard or not rather by a specific application?
Nonetheless, I think the BLW should provide datasets/lists which contains all the information required.

Additionally we need a mapping of species and varieties.

Currently, agronomicCropCategory (see

eCH-0265/src/eCH-0265-1-0.xsd

Line 427 in 4b5d9be

<xs:complexType name="agronomicCropCategoryType">

) is an enumeratedType. The link between the CropCategory and the botanical species is done thanks to the botanicalPlantType complex type. See:
https://github.com/blw-ofag-ufag/eCH-0265/blob/4b5d9be03984dcf3ec2024519458119a873086de/src/eCH-0265-1-0.xsd#L350C24-L350C42
and

eCH-0265/src/eCH-0265-1-0.xsd

Line 395 in 4b5d9be

<xs:element name="agronomicCropCategory" type="eCH-0265:agronomicCropCategoryType">

Since the botanical plants are meant to be taken from the EPPO database, I think we should rework the whole.

I agree whole-heartedly!

• botanicalPlantType should simply be a reference to an EPPO code. We should not publish a codelist for that, since the master will be EPPO.

• agronomicCropCategory should be expanded from a "simple" enumeratedType to a complexType including not only a code and description but also a list of valid EPPO codes. The list of valid EPPO codes for each agronomicCropCategory must be delivered by subject matter experts.

Alternative suggestion: instead of building more complex datasets, we could splint into several lists/datasets. Finding the relevant master and holding the dataowners accountable might prove way simpler.

• botanicalPlant should be of enumType with the EPPO-Code as code.
• varieties should be of enumType with the UPOV-Code as code.
• BLW should provide a dataset (or 2 lists?) for varieties containing the ids of zugelasseneSorten, geschützteSorten.

BLW should provide a dataset or various lists for each agronomicCropCategory: agronomicCropCategory must be of [EPPO_code | UPOV_code].
Additionally, BLW should provide a dataset or various lists for each directPaymentCrop: directPaymentCrop must be an element of [EPPO_code | UPOV_code]. (i.e. a more stripped down version of directpaymentcropDataset.xml using only ids)

Other miscellaneous info:

• The agronomicCropCategory are the GRUD crop categories. We should understand where the authority is and initiate the mapping to EPPO codes.

Yes - but perhaps GRUD is not the master! We need to identify the master - and the BLW should refer only to this dataset.
For example, the list "Katalog landwirtschaftliche Hauptkulturen" can be found here: https://www.blw.admin.ch/blw/de/home/politik/datenmanagement/geografisches-informationssystem-gis/landwirtschaftliche-kulturflaechen.html. The document's title however is "LNF_Katalog_Nutzungsart" indicating that there might be a different master still, i.e LNF? Or vice versa...

• It is possible that directPaymentCropType (https://github.com/blw-ofag-ufag/eCH-0265/blob/4b5d9be03984dcf3ec2024519458119a873086de/src/eCH-0265-1-0.xsd#L444C24-L444C45) is in a similar situation. It is, however, already a complexType and not an enumeration. This type is linked to a variety instead of a botanical species. We should check if this link makes sense or should rather be handled the same way as for the agronomicCropCategory.

• digiFLUX would like to see this changes (better link of agronomicCropCategory with a botanical species) by the end of September 2025

Might be feasible but is still ambitious. The changes suggested will be a major change that needs the ok by AG Agrardaten. Let's first rework the structure of the species by rearranging only the already used elements. This ideally would need the least changes for the Umsysteme.

How do we include Varieties into the modell? Are varieties an element of species? Or are species an element of varieties? This is especially relevant having the question in mind: How to deal with crossbreeds?
Or do we not need to modell this as all the information can be mapped using the lists provided?

@hurni your thoughs on that?