Professional
Gen4Olive Field App
The field application for an EU Horizon 2020 project on olive genetic resources: camera capture and model-assisted cultivar and disease recognition, for agronomists working in a grove.
Gen4Olive is an EU Horizon 2020 research project on olive genetic resources. The field application is the part an agronomist actually holds: point a phone at a leaf or a fruit, and get back candidate cultivars or candidate diseases, with the reference material for each.
- Context
- EU Horizon 2020 research project
- Engagement
- Freelance, Nov 2024 – Mar 2025
- Scope
- 600+ olive cultivars
- Stack
- React Native · Expo · JavaScript
- Repository
- Private, SystemsLab-Sapienza
The problem
The users are agronomists, and the place they need this is a grove: outdoors, one-handed, on a phone, frequently without a usable connection, and under light conditions nobody chose. The reference material for hundreds of cultivars exists, but it is organised for reading rather than for identifying the tree in front of you.
What I built
An Expo/React Native application in four parts.
Capture. Camera and gallery input, with image manipulation applied before anything is sent: the photograph a phone produces is not the input a model expects, and normalising it in the app is what keeps the recognition step consistent across devices and lighting.
Recognition. Two prediction paths, one for cultivar and one for disease, each posting the prepared image to its own endpoint. Inference is server-side; the app is the client. The response is rendered as a list of candidates rather than a single answer, and every candidate links through to its reference entry.
Reference. The cultivar and disease material, structured for lookup – browse, list, detail – so that a suggestion can be confirmed against the source rather than trusted.
Localisation. i18next over a translation bundle, with the device locale detected at startup, because the consortium spans several countries and the people using it in a field are not necessarily reading English.
Hard parts
The model is a suggestion and the interface has to say so. The recognition result is presented as ranked candidates, each one navigable to the underlying reference entry. That costs a tap compared to showing one answer, and it is the difference between assisting an expert and asking them to trust a black box they cannot check.
Preprocessing on the device, inference off it. Splitting the pipeline at that seam keeps the model replaceable without shipping an app update, and keeps the app small, at the cost of a network round trip in exactly the environment least likely to have one.