logo Calflora Weed Manager Design
Design of the Weed Manager System     Updated August, 2017


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 ID *
group ID
user ID (member)
group ID *
user ID (owner)
Each group can have many projects associated with it:
Project 1
Project 2
Project 3
Project 4
. . .

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 ID *
user ID
group ID
plant list
Data objects associated with a project
Plant List

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 ID *
user ID
group ID
project ID
root record ID
shape ID
location description
number of plants
gross area
infested area
percent cover
location accuracy
percent treated
observation ID

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: ease of access (how easy is it to get to the population), and priority (how important is it on a scale from 1 to 5).

root record ID
shape ID
ease of access
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,

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 also be uploaded from desktop GIS software (for instance, to define regions).


shape ID *
user ID
group ID

Session (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 reference ID.

    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.

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

If an organization uses this table as in 1. above, then it would also be possible to report on resources used for a particular weed (time spent doing assessments or treatments).


session ID *
user ID
group ID
project ID
reference ID
number of people
number of hours

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 ID *
user ID
group ID
project ID
shape ID
location description
survey ID
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)