Introduction
Farm maps in LiteFarm allow users to add three types of drawings locations to their farm maps: areas, lines, and structures.
Areas are drawn polygons that have area. In general, the utility of the polygon is tied to its size. Examples of areas include fields, natural areas, residences, barns, greenhouses, etc.
Lines are drawn, multi-point segments that don’t form a closed polygon. In general, lines don’t have an area (such as with fences) or their area is relatively uniform and based on the direction of the line (such as with creeks or buffer areas). Examples of lines are: fences, creeks, roads, and footpaths
Points on the other hand are coordinates that are dropped on the map. For all intents and purposes, they don’t have an “area” per se, but rather provide a service based on their location. Examples of structures include water valves and gates
Areas
For our Spring 2021 release, the following areas will be supported:
Area type | Attributes | Other notes | Available Views |
|---|---|---|---|
Farm site boundary |
| Detail | |
Field |
| Total area and perimeter should be pre-populated by the maps API, but modifiable by the user. Organic status: {“Non-organic” (default), “Transitional”, “Organic”) Transition date only shown if transitional chosen. |
'* including retire, reestablish |
Garden |
| Total area and perimeter should be pre-populated by the maps API, but modifiable by the user. Organic status: {“Non-organic” (default), “Transitional”, “Organic”) Transition date only shown if transitional chosen. |
'* including retire, reestablish |
Barn |
| Total area should be pre-populated by the maps API, but modifiable by the user. Both enums have the following values: {““, “No”, “Yes”} |
'* Not in current scope - just an FYI ** including retire, reestablish |
Greenhouse |
| Total area should be pre-populated by the maps API, but modifiable by the user. Organic status: {“Non-organic” (default), “Transitional”, “Organic”) Transition date only shown if transitional or organic are chosen. |
'* including retire, reestablish |
Natural area |
| Total area and perimeter should be pre-populated by the maps API, but modifiable by the user. |
|
Groundwater |
| Total area and perimeter should be pre-populated by the maps API, but modifiable by the user.
|
'* including retire, reestablish, redraw (per seasonal fluctuations) |
Residence |
| Total area should be pre-populated by the maps API, but modifiable by the user. |
|
Ceremonial area |
| Total area and perimeter should be pre-populated by the maps API, but modifiable by the user. |
|
Lines
For our Spring 2021 release, the following lines will be supported:
Line type | Attributes | Other notes | Available Views |
|---|---|---|---|
Fence |
| Length should be pre-populated by the maps API, but modifiable by the user. Fences that are pressure treated need to be declared for organic certifications. Only shown for organic certification. Options: {““, “Yes”, “No”} |
|
Watercourse |
| Length should be pre-populated by the maps API, but modifiable by the user. Used for irrigation: {““, “Yes”, “No”} Includes riparian buffer: {““, “Yes”, “No”} |
|
Buffer zone |
| Total area and perimeter should be pre-populated by the maps API, but modifiable by the user. Width is required. Standard is 8 meters for separation of organic and non-organic areas - though there are many reasons it can be less. Must be modifiable. |
|
|
| Length should be pre-populated by the maps API, but modifiable by the user. Type: {“Earthen” (default), “Gravel”, “Paved”} |
|
|
| Length should be pre-populated by the maps API, but modifiable by the user. Type: {“Earthen” (default), “Gravel”, “Paved”} |
|
Points
For our Spring 2021 release, the following points will be supported:
Point type | Attributes | Other notes | Available Views |
|---|---|---|---|
Water valve |
| Water source: {“Municipal water” (default), “Surface water”, “Groundwater”, “Rain water”} Flow rate unit is based on the users measurement preference. For metric: l/min, l/hour (default) For imperial: g/min (default), g/hour |
|
Gate |
|
|
Handling interactions between locations
In the general case, locations are assumed to be independent from each other. For example, if a user decided to draw a farm site boundary and then chose to draw a field outside this boundary, it is not the system’s responsibility to warn or prevent the user from doing this. Instead, the system assumes the user can make their own choices in this regard as long as the user is provided with the appropriate contextual information, specifically:
Users can view existing locations while adding new locations
Users can zoom in and out and change the viewed area while adding a new location
After placing a new location, users can modify it while viewing existing locations
One specific example of this general case is overlaps between areas. If a user decided to create a large field and then place a residence partially or entirely within the field, that is their prerogative. The areas of each will be calculated independently.
The reason we’re laissez faire about these interactions are two fold:
For certifications or research where areas are being compared someone will look at the visual map
Users can override areas and perimeters when they create a shape (such that if I knew my field was 10,000 sq ft and my house 2,000 sq ft in the above example, I could overwrite the field area to be 8,000 sq ft to compensate)
However, there is one case where we do want to supervise overlaps.
Transitioning from legacy fields to areas, lines, and points
...