General:
Layers are a feature that can be “overlaid” on the farm map in order to provide additional insight to the user. They do not fundamentally change what the map is, but they do provide specific guidance on an important aspect of farming. Google maps utilizes several layers to provide guidance to specific users…
Such as bikers (combined road and bikelane maps)…
And hikers (combined topography and trailmap)…
Similar to the above examples, we’re seeking to give farmers additional insights when they add Layers to their farm map in order to guide decision-making on the farm. For example, knowing the soil textures at different places on a farm can guide a user to plant specific crops in specific places. Likewise, knowing topography will inform where precipitation is likely to have a greater or lesser effect on growing crops.
Layers share some qualities of a location, specifically areas, but also differ in important aspects as well. The following are a non-exhaustive list of Layer qualities to help orientate.
Similarities:
Collection of grid points
Collection of attributes
Type of layers extend the attributes of a generic layer (in similar fashion to how specific location types extend properties of generic locations)
(Some) layers are user generated using the add flow on the farm map
Layers can be shown or hidden using a map filter
Layers can be included or excluded from a farm map export
Differences:
Crops and tasks can’t be applied to layers (open discussion)
Layers can consist of any number of polygons (rather than only 1)
Layers may have different attributes at different depths (e.g. soil texture at 0 - 10cm vs. 50 - 100cm)
Only 1 of each type of layer can be “active” at a given time (though we should probably allow multiple different layers to be active simultaneously)
Though Layers maintain a history
Other attributes of layers:
Some are static (such as topography) while others are dynamic (such as soil water deficit)
How are Layers created:
Some Layers, specifically those that are largely static and public information*, should be generated behind the scenes as farms are created. Examples of this type of layer include:
Topography:
Soil texture: Soil grids
Query at farm onboarding for an assumed bounding box. Then update as locations are added
Others will be uploaded by the user based on special knowledge they have. Examples of these layers include:
Soil electroconductivity
Soil salinity
Still others should be dynamically generated by LiteFarm or an external service as conditions on the farm change. Examples of this class of Layers include:
Soil water deficit
Organic vs. non-organic locations on the farm
* A quick note on “public information”. Quality of public data across the world varies widely. For example, you might imagine that soil textures are well understood in farming breadbaskets such as Iowa and Ontario and less well known or documented in rural parts of Uganda. As such, we’ll always need to support the ability for users to upload their own versions of an otherwise static and publicly available map.
Zones
Some layers will likely consist of many zones. A zone is a collection of grid_points that form a polygon. Each zone of the Layer has the same attributes, but may have different values. For example, all zones in a soil texture Layer will have a “percent_sand” attribute, but for Zone 1 it may be 44% while for Zone 2 it may be 36%.
Historical / forecast
For some Layers, we likely want to keep a version history of the layer over time. One example of this would be an irrigation prescription. It seems likely a farmer would want to be able to refer back to how much water they’ve put on their field after executing on a given irrigation prescription.
Other types of Layers that are based on data queried within LiteFarm will have attributes related to dates and times that make seeing a history or forecast by querying on those dates and times easily achievable. For example, by activating a “Number of tasks at each location” Layer, you could imagine a slider bar that could select specific historical or upcoming dates and query for tasks where the due date, completion date, or abandonment date fell on that date.
Examples of Layers
Should we be able to assign a task to a layer?
Likely beneficial for the user! May be difficult to implement. Example David gave is “Take a soil sample from all organic locations on the farm”. In order to do this the system would need to be able to:
Differentiate different location / zone statuses for grouping (e.g. organic, non-organic, transitioning)
Specify a task type for teach of the grouped locations / zones
Link together in a flow each task x location pairing so that the user can provide details specific to that pairing (e.g. a lat / long within a area for the soil sample to be taken)
Easier to implement would be the ability to identify locations that fall into a specific grouping (e.g. organic locations) and then easily select those to create a task.
Should there be a default “on click” action defined for each layer?
Seems reasonable.
One example: Looking at a layer for “number of tasks on each location for a given day” - what should clicking on a location showing 5 do? Seems logical that it would take the user to the task homepage filtered for that date.
How should we handle layers that have a vertical component? For example, with soil texture we might want to define the soil texture attributes for different strata, e.g. 0 - 10 cm, 11 - 30 cm, 31 - 50 cm, 51 - 100 cm.
How do we handle zones that are nested within other zones on a layer (e.g. a hill in a topography layer)?
Should we support multiple visible layers at the same time?
If we support multiple visible layers at a time, how should they display when overlapping?
For performance reasons, should we limit the number of zones a user can upload for a given Layer?