There are several answers to this question:
The Soil Mate apps design will be such that it should be flexible enough to capture any type of soil data. Instead of reinventing the wheel, I thought I’d just use the same structure that is used in FarmOS (taxonomies/assets/logs) and matching keys. I think that if the AgTech industry is to move towards a future of cross-platform capabilities and integrations, we are going to need some sort of standards. The farmOS API seems like a good place to start. Plus it’s open-source, so it philosophically aligns.
At the moment, the app captures soil textures (clay, loam, sandy-loam, etc…) but we have a client who wants to add soil ground cover observations as well. I foresee that as the app continues to get uptake the demand for new features will increase and I want to make sure it scales (eg soil samples, soil attributes, weeds, etc…). The FarmOS
taxonomy_terms is a really logical way to structure it. The vision is to update the
taxonomy_term.json (saved in the app) file and the UI will automatically add an observation/survey type.
We believe that farm data is precious and that the user should have full control over their data. The default method the export the data is to attach a
.csv to an email (or app of your choosing); no server required.
These are, however, limitations to this; including:
- not being able to change the device
- not being able to share data between users
- limitations on the size of the data (no hi-res images)
I want to give the user the option to add a FarmOS server by simply adding in the settings. Something like:
Sync with a FarmOS server
And as a bonus, they can use the FarmOS UI to manage their data.
I also have other projects that I plan to user FarmOS as the DB/data management system.