logo Calflora Weed Manager Design
Design of the Weed Manager System     Updated July, 2020

Overview

Weed Manager is intended to be used by various organizations engaged in land management. The primary purpose of the system is to track weed infestations over time, and the treatments applied to those infestations. Each organization which subscribes essentially uses a private copy of the system, but has the option of sharing their data.

Each organization which subscribes to Weed Manager can configure certain aspects of how they want to use the system -- for instance, by choosing which fields are required, or which extra fields they want to collect for an assessment. The core data fields and the core methodologies remain standard across all organization subscribers, however, thus enabling data exchange and integration.

The key is a design flexible enough to meet the needs of a variety of land management organizations. This document suggests such a design in the form of a data model, which represents an evolution of the Calflora data model.


General Requirements

The system as a whole

  • accomodates multiple organizations as clients, and allows each to work privately and securely on their own data;
  • provides methods of data collection and data extraction that are both applicable to many organizations and customizable by each orgnization;
  • imposes a certain uniformity on the structure of data collected, but within that, allows each organization to define exactly what and how data is collected.
Each client organization
  • chooses their own policies regarding data collection: which fields to collect, and which are required;
  • is able to create new projects as needed;
  • is able to search, edit, extract and otherwise maintain all data associated with a project;
  • is able to assign certain individuals the Data Czar role (the ability to edit any record belonging to the organization).
Each individual user
  • when doing data entry, can choose between the organizations of which they are a member, and within each organization, can choose between projects;
  • can edit and maintain the records they contribute in a way that is consistent with the policies of the chosen organization and project.

Required Specific Features

The term occurrence (sometimes also population) is understood to mean a single patch of a particular plant. An occurrence has a history over time, which can be abstractly characterized in a sequence of observations (assessments or treatments) of that occurrence.

With Weed Manager, many assessments can be entered for a single occurrence. Many treatments can be entered for a single occurrence. The Plant Observation Entry (POE) web application is able to show the assessment and treatment history of an occurrence, including lines and polygons.

Weed Manager also provides a way to track the number of people and the number of hours spent doing data collection and treatment.

Data Model

Group (Organization)
A organization subscriber is represented in the database by a group record. A group is owned by a particular user (user ID). The owner controls which other users are in the group, and what roles each user has in the group.

Membership in a group is indicated by a group_member record, which associates a user (user ID) with a group (group ID).

Every observation record (see below) is owned by a particular user (user ID), and may also be associated with a particular group (group ID). A user can always edit the weed records which he or she owns. In addition, if a user is a member of a group, and has been given the Data Czar role by the owner of that group, then that user can also edit any weed record associated with the group.

The presumption is that an organization will have many people entering data. If there are one or two people who are willing to assume responsibility for the uniform quality of data collected, then they should have the Data Czar role.

 

user
user ID *
name
email
group_member
group ID
user ID (member)
role(s)
group
group ID *
user ID (owner)
description
Each group can have many projects associated with it:
 
Group
Project 1
Project 2
Project 3
Project 4
. . .

Project
An organization may be engaged in multiple projects, where each project is distinct from other projects by the area it covers, by the target plant(s), or by some other aspect of data collection methodology. A project is represented in the database as a project record. An organization needs to define at least one project.

A project record contains all of the background data needed to do focused fieldwork in a particular area: gathering data for new occurrences, re-assessing known occurrences, or doing treatments. When using the phone app, a user can choose between their organization's various projects.

A project might be as simple as a general description of the weeds of concern in an area. It could also describe the plants and occurrences to be re-assessed and/or treated in an area during a particular field season.

The plant list is a list of target plants.

The FORM contains the fields that a user will be presented with when doing data entry, either with the phone app or with the Plant Observation Entry (POE) web application.

 

project
project ID *
user ID
group ID
name
description
plant list
FORM
observations
Data objects associated with a project
 
FORM
Plant List
Observations


Assessment and Treatment
The observation table is used to store both assessment and treatment records. The initial record of an occurrence is called the root -- ideally it is a complete assessment of the occurrence. Subsequent records of the occurrence refer to the root record by root record ID.

Assessment and treatment records have certain fields in common, such as taxon. When entering a new assessment linked to a root record, the taxon, latitude and longitude fields are copied into the new assessment from the root record.

As data builds up over time, a root observation can end up with many assessment and treatment records linked to it (see this Diagram below).

(The absence of a plant in an assessment is indicated by setting the value of number of plants to 0. Any assessment with the value of number of plants other than 0 indicates presence.)

An assessment record can be associated with a shape record (shape ID), where the shape record contains a line or polygon describing the extent of the plant at that location.

A treatment record can be associated with a shape record (shape ID), where the shape record contains a line or polygon describing the area that was treated.

Exactly which fields are required for either an assessment or a treatment is up to the organization -- for instance, an organization may decide that a polygon or line is required for an assessment record. An organization can also include additional assessment fields or additional treatment fields in a form.

 

observation
COMMON FIELDS:
observation ID *
user ID
group ID
project ID
root record ID
shape ID
date
taxon
calrecnum
observer
latitude
longitude
location description
habitat
ASSESSMENT FIELDS:
phenology
number of plants
gross area
infested area
percent cover
location accuracy
TREATMENT FIELDS:
method
percent treated
photo
observation ID
URL
credit
caption

History Stack
It is possible to build up a picture of how a patch is changing by doing multiple assessments (and/or multiple treatments) of the patch over time, and linking each one back to the original observation record.

The end result is a stack, or an assessment and treatment history of the occurrence.

On the right is a way to visualize this kind of history: The weed was discovered at a particular spot in 2012, and most recently assessed there in 2016.



 
most recent assessment 2016
|
assessment and treatment 2015
|
assessment and treatment 2014
|
assessment 2013
|
earliest or root record 2012

The Population Record: Reference Polygon
When a history stack has polygons. a population record is automatically created for it. The population record is linked to the stack by means of root record ID. One of the polygons that belongs to a record in the stack becomes the reference polygon for the stack. The population record is linked to this polygon by means of shape ID. Typically, the reference polygon is the one from the oldest record in the stack.

The reference polygon is used to represent the stack in graphical situations where many records with polygons are displayed at the same time; for instance, in the Nearby function of POE, or in the Plant Distribution application. You can change the reference polygon in POE when you are editing any one of the records in the stack.

A population record also has other optional fields:

    Access to the Site (how easy is it to get to the population, on a scale from 1 to 10),

    Priority (how important is it, on a scale from 1 to 5), and

    Plant Count (a summary of plant counts from the previous calendar year).




population
root record ID
shape ID
access to the site
priority
plant count
Here is a population of Scotch Broom displayed in POE. The blue line shows the reference polygon, drawn when the patch was first recorded. The red line shows the polygon of an assessment record in the stack several years later. The size of the patch has been reduced by treatment,


Shape
The shape table holds user-defined shapes for several purposes:

  1. lines or polygons describing the extent of a patch of weeds;
  2. polygons describing the extent of a treatment;
  3. polygons defining regions or sub-regions;
  4. polygons defining survey areas;
  5. polygons defining the geographical extent of a search.


Both name and group ID are optional.

When a shape is named, it can be used again by the owner, possibly for another purpose or in a different application. When a shape is named and associated with a group, it can be used again by any member of the group. The idea of named shapes is to minimize the need to re-enter shapes.

Named shapes can be defined and used in various applications. They can be uploaded from desktop GIS software with the Shape Editor application -- for instance, to define trails, management units, or regions.

 

shape
shape ID *
user ID
group ID
date
name
geometry
Google Maps and Spherical Geometry
Calflora web applications and the Android Observer Pro phone application utilize Google Maps for displaying points, lines and polygons. All coordinates are in latitude and longitude, WGS84 datum. Polygon area calculations are performed with the Google Maps Geometry Library API utilizing spherical geometry instead of a projection. Quote:

"Within 2D projections, appearances can sometimes be deceiving. Because the map projection necessarily requires some distortion, simple Euclidian geometry often is not applicable. For example, the shortest distance between two points on a sphere is not a straight line, but a great circle (a type of geodesic), and the angles that make up a triangle on the surface of a sphere add up to more than 180 degrees.

Because of these differences, geometric functions on a sphere (or on its projection) necessitate using Spherical Geometry to calculate such constructs as distance, heading, and area. Utilities to calculate these spherical geometric constructs are contained within the Maps API's google.maps.geometry.spherical namespace. This namespace provides static methods for computing scalar values from spherical coordinates (latitudes and longitudes).
"
Don't fence me in

Don't projection me in


Work Performed
The session table represents a subsystem for tracking the resources (hours and people) spent doing weed work. The use of this subsystem is optional.

A session record indicates how much work was done on a particular day in a particular activity. The possible values of activity are specific to a group, and managed in the Group Options application.

There are two ways an organization might use this table.

    1. Whenever an observation record (assessment or treatment) is entered, the user also enters the number of hours and the number of people involved, and the system generates an accompanying session record, associated with the observation record by observation ID (also called "reference"). There can be more than one session record for a single observation record -- for instance, if treatment was involved, and if more than one crew worked on the treatment, then there could be a session record for each crew.

    2. The user enters session records explicitly to represent the summary of a day's activity. This kind of session record is not tied to a particular observation record.


Reports. In either case, all tracking of work performed (number of hours) happens by means of this table, which makes it straightforward to report on the amount of hours spent during a time period or doing a paricular activity.

If an organization uses this table as in 1. above, then it is also possible to report on hours spent working on a particular weed (doing assessments or treatments), in a particular area, or both.

 

session
session ID *
user ID
group ID
project ID
date
activity
observation ID
number of people
number of hours
observation
observation ID *
user ID
group ID
project ID
root record ID
shape ID
date
taxon
calrecnum
observer
latitude
longitude
. . .

Survey
A survey is an organized effort to find certain plants in a certain area. The result of performing a survey is a list of the plants that were found and the plants that were looked for but not found (absence).

In Weed Manager, you can enter a survey record with the Survey Editor.

  1. Enter a new survey record called, for instance "Northeast addition weed survey spring 2017."
  2. Define the survey area with a named polygon; for instance; "Northeast addition," and add it to the survey record.
  3. Add a plant list (containing whatever weeds are expected there) to the survey.
  4. In the Survey Editor, you can search for observations from a certain group in a certain area for certain plants during a span of dates, and add some or all of those records to the survey.
  5. If someone looks for a particular plant in the area and does not find it, they should enter number of plants = 0.
  6. The duration of the survey can be whatever is required: one day, or two months.  
 

survey
survey ID *
user ID
group ID
project ID
shape ID
date
observer
latitude
longitude
location description
habitat
survey_plant
survey ID
taxon
calrecnum
number of plants
percent cover

More Information

Current Documentation

Weed Manager Home

Plant Observation Entry HELP

Group Observations HELP

Survey Entry HELP

Historical Documentation

Weed Manager Use Cases

Comparison with Geoweed

Updating Geoweed Robert Steers, from the October 2012 Cal-IPC Symposium

Comments about improvements to Geoweed and discussion, from the October 2012 Cal-IPC Symposium.

Calflora Data Models

The OATS Model

Data Acquisition and Management in Calflora (data privacy and groups)