logo Calflora Weed Manager Design
Proposed Design of the Weed Manager System, Updated June, 2014  v. 0.53


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 will essentially be using a private copy of the system, but will have the option of sharing their data with other subscribing organizations within the system, other Calflora users, and with other systems such as CalWeedMapper.

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 to have a design which is 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 current Calflora data model.

General Requirements

The system as a whole will

  • accomodate multiple organizations as clients, and allow each to work privately and securely on their own data;
  • provide methods of data collection and data extraction that are both applicable to many organizations and customizable by each orgnization;
  • impose a certain uniformity on the structure of data collected, but within that, allow each organization to define exactly what and how data is collected.
Each client organization will
  • set up their own policies regarding data collection: which fields to collect, and which are required;
  • be able to create new projects as needed, where each project is defined by an area, a plant list, and a time period;
  • be able to assign individuals (members of the organization) to work on a particular project;
  • be able to search, edit and otherwise maintain all data associated with a project;
  • be able to assign certain individuals the Data Czar role (the ability to edit any record belonging to the organization).
Each individual user will
  • when doing data entry, be able to choose between the organizations of which they are a member, and within each organization, be able to choose between projects;
  • be able to 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
Many assessments can be entered for a single occurrence (consistent with OATS). Many treatments can be entered for a single occurrence. A web application will be able to show the entire assessment and treatment history of an occurrence, including lines and polygons.

A single treatment record can be assigned to multiple adjacent occurrences, possibly of different plants.

The system will track the number of people and the number of hours spent doing data collection and treatment.

Whenever possible, fields will be supplied by the system or auto-populated.

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

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 will be able to 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 plants, or by its time period. 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. It is also the a way to organize a multi-species survey in an area over a certain time period.

The plant list is a list of target plants. The occurrence list is a list of known occurrences to be re-assessed or treated, produced from search criteria. A project record includes an indication of the area covered in the form of an associated polygon (a shape record, shape ID).

Field sets are the fields that a user will be presented with when doing data entry, either from the phone app or from a web application. The idea of configurable field sets is to make data entry as fast and focused as possible. There are typically three: one for occurrence records, one for assessment records, and one for treatment records.


project ID *
user ID
group ID
plant list
occurrence list
(from search criteria)
field sets
shape ID
Composition of a project record:
Plant List
List of Occurrences
(to be re-assessed or treated)
Field Sets

Occurrence and Assessment
The observation table will be used to store both occurrence and assessment records. Functionally, the difference between these two record types is a matter of sequence: an occurrence record is the first observation of a particular weed at a particular spot; it may include assessment field values, or not. An assessment record is a subsequent observation of the same weed at the same spot, and it refers to the original or root observation by root record ID.

Both types of record have certain fields in common, such as taxon. When entering an assessment linked to a root observation, the taxon, latitude and longitude fields are copied into the new assessment from the root observation.

As data builds up over time, a root observation can end up with many assessment 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.

Exactly which fields are required for either an occurrence or an assessment 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 specify extra occurrence fields or extra assessment fields.


observation ID *
user ID
group ID
project ID
location description
extra fields
root record ID
shape ID
number of plants
gross area
infested area
percent cover
location accuracy
extra fields
observation ID

A treatment event record represents the situation when one or more occurrences are treated on the same day using the same treatment method. Each occurrence that is treated during a treatment event is indicated by a treatment-occ (read: treatment of an occurrence) record, which associates the treatment event (trevent ID) with the occurrence (root record ID). The occurrences referred to may all be of the same plant, or of different plants.

A treatment event record is associated with a project (project ID). A treatment event record can optionally be associated with a shape record (shape ID), where the shape record contains a line or polygon describing the extent of the treatment.

Exactly which fields are required and which are optional in these records is up to the organization. An organization can also specify extra fields to be included in a treatment event record. For instance, an organization might want to include quantity of material removed (either bags or cubic yards) as an extra field in a treatment event record.


treatment event
trevent ID *
user ID
group ID
project ID
shape ID
herbicide name
extra fields
trevent ID
root record ID
percent treated
A treatment event is associated with possibly many treatment-occ records (one for each occurrence treated during that treatment event).

An organization can define its own set of values for treatment method. Here is one possible set of values:

Shovel shear Handpull
Flower or seed removal Mow
Lop Herbicide

If the value is Herbicide, then herbicide name and concentration also need to be specified.

Assessment and Treatment History
In a OATS model system, 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 occurrence 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 2009, and most recently assessed there in 2013.

most recent assessment 2013
assessment and treatment 2012
assessment 2011
assessment 2010
earliest or root record 2009

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

  1. shapes describing the extent of a patch of weeds;
  2. polygons defining regions or sub-regions;
  3. polygons defining survey areas;
  4. polygons deifining 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 occurrence, assessment, treatment, or other.

There are two ways an organization might use this table.

    1. Whenever a weed data record (occurrence, assessment, or treatment event) is entered, the user will also enter the number of hours and the number of people involved, and the system will generate an accompanying session record, associated with the weed data record by reference ID.

    2. Session records are entered explicitly by themselves (not associated with specific weed data records), and act as a summary of a day's activity.

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 an 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 gathering occurrence data and 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, the way to organize a multi-species survey is by 1. defining a project with the parameters of the survey in it, and 2. using a special search to extract the results of the survey. Here are the steps:

  1. Set up a project called, for instance "Northeast addition weed survey spring 2014."
  2. Define the survey area with a named polygon; for instance; "Northeast addition," and add it to the project.
  3. Add a plant list (whatever weeds are expected there) to the project.
  4. People participating in the survey will associate their observation records with the project.
  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.
  7. At the end of the survey period, do a special search for observations associated with the survey project. The search results will be broken into two broad groups:
    • plants found (including count, locations, etc.), and
    • plants looked for but not found.
Composition of a project record used for a survey:
Project Record
Plant List
(as a named polygon)
Observation 1
Observation 2
Observation 3
Observation 4
Observation 5
Observation 6
. . .


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

Current Calflora Data Models

The OATS Model

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