After integrating the Farm Calendar, we noticed a huge complecity with tightly coupled dependecies between endpoints.
We could suggest simplifying the service by introducing types of activities that can be traced back to macro-areas, for example:
- Fertilization which can include subactivities as operator, vigour observation, vegetation indices calculation, crop stress indicator, fertilizer type (including organic compost etc.), dose, agricultural machinery (fertilizers spreader) and everything related to this;
- Irrigation hold features like operator, water stress maps, observations, irrigation type, amount, and so on;
- Pest and disease including subactivities like operator, treatments, observations, pest to fight (causative agent) alerts, spraying raccomandation, pesticides active principle and doses, date and time of the treatment, agricultural machinery (sprayers) used for the treatment, and everything close to the topic;
- Crop data that can include observations, drone or satellite info, crop map, yield prediction, crop growth observations, quality certification (DOP and IGP) and so on;
- Livestock section to include specific operation about animal farm management.
We believe that few types of activities should be identified (ideally 5-6 as shown above) and that they cannot be modified by the user. Conversely, the sub-activities can be multiple and some identified (see suggestion above) and others customizable by the user. This would make the user experience (mainly farmers and agrotechnicians) much smoother and increase its attractiveness. We must give the farmer an intuitive and easy-to-use tool, not something too dispersive or complex that could reduce its use in the long run.
PS. The Farm Parcel includes “valid from” and “valid to” but it is inconsistent with agronomic perspective. These fields add noise to the data entry workflow and risk being misused or left inconsistently populated. A farm parcel is a physical, geographically defined land unit. Its existence is not inherently time-bounded in the way the current data model implies.
PPS. Please male "Agricultural machinery" optional inside the activity, because some field operations do not involve machinery.
Keep me update on this :)
After integrating the Farm Calendar, we noticed a huge complecity with tightly coupled dependecies between endpoints.
We could suggest simplifying the service by introducing types of activities that can be traced back to macro-areas, for example:
We believe that few types of activities should be identified (ideally 5-6 as shown above) and that they cannot be modified by the user. Conversely, the sub-activities can be multiple and some identified (see suggestion above) and others customizable by the user. This would make the user experience (mainly farmers and agrotechnicians) much smoother and increase its attractiveness. We must give the farmer an intuitive and easy-to-use tool, not something too dispersive or complex that could reduce its use in the long run.
PS. The Farm Parcel includes “valid from” and “valid to” but it is inconsistent with agronomic perspective. These fields add noise to the data entry workflow and risk being misused or left inconsistently populated. A farm parcel is a physical, geographically defined land unit. Its existence is not inherently time-bounded in the way the current data model implies.
PPS. Please male "Agricultural machinery" optional inside the activity, because some field operations do not involve machinery.
Keep me update on this :)