include possibility to indicate agriculturalRegion

[hurni]

eCH-0261 contains agriculturalZone. Missing is agriculturalRegion.
More info @cornelia Schmid; @simon Frey

possibile solutions:

a) add agriculturalRegion (two possible values: "Talgebiet", "Berggebiet"); resulting in a minor change
b) indicate acres per zone to calculate the region; resulting in a major change

initial evaluation (cp. example below)

pro b): nice modular setup -> data can be used to calculate 2 relevant indications
pro a): if usage is limited to calculating agriculturalZone and agriculturalRegion, instead of two datapoints, up to 6 datapoints would be needed. Can be realised with backwards compatibility.

---

example: localUnit has
20 Aren Talzone
30 Aren Hügelzone
40 Aren Bergzone 1

localUnits agriculturalZone is "Bergzone 1" (as 40 Aren = grösste Fläche), agriculturalRegion is "Talgebiet" (20 + 30 Aren = 50 Aren = grösste Fläche)

see mail:
Von: Schmid Cornelia BLW cornelia.schmid@blw.admin.ch
Gesendet: Dienstag, 15. Oktober 2024 16:25
An: Hurni Pascal BLW pascal.hurni@blw.admin.ch
Cc: Altorfer Alexandra BLW alexandra.altorfer@blw.admin.ch; Foletti Ambrogio BLW ambrogio.foletti@blw.admin.ch
Betreff: AW: eCH-0261: Gebiet (area)

[AFoletti]

This is a minor that could be implemented in V1.5

[hurni]

added to https://github.com/blw-ofag-ufag/eCH-0261/blob/Release-1.5.0/src/eCH-0261-1-0.xsd

[montanajava]

In the XSD it would appear that a String representing an integer is being used as a key for the value, e.g. "01", "02".

Humans, not just machines, also read the transmitted values and it would be nice if one could discern what is meant by 01 or 02 without having to resort to looking it up in the XSD.

Would "MOUNTAIN" and "VALLEY" be worth considering as keys, notwithstanding the fact that in other enumerations within this standard integer values as strings were used?