...
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
...