Proposed Design of the Weed Manager System, June, 2013 v. 0.52
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
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
current Calflora data model.
The system as a whole will
Each client organization 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 individual user 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).
- 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
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
Comments about improvements to Geoweed
and discussion, from the October 2012 Cal-IPC Symposium.)
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)|
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
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
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 * |
(from search criteria)
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
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
Any assessment with the value of number of plants
other than 0 indicates presence.)
An assessment record can be associated with a
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 * |
|root record ID |
|number of plants|
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
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.
|trevent ID * |
|trevent ID |
|root record ID |
An organization can define its own set of values for
Here is one possible set of values:
|Flower or seed removal
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|
earliest or root record 2009
The shape table holds user-defined shapes
for several purposes:
- shapes describing the extent of a patch of weeds;
- polygons defining regions or sub-regions;
- polygons defining survey areas;
- 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
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 *|
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
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
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 *|
|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:
- Set up a project called, for instance "Northeast addition weed survey spring 2014."
- Define the survey area with a named polygon; for instance; "Northeast addition,"
and add it to the project.
- Add a plant list (whatever weeds are expected there) to the project.
- People participating in the survey will
associate their observation records with the project.
- If someone looks for a particular plant in the area
and does not find it, they should enter
number of plants = 0.
- The duration of the survey can be whatever is required: one day, or two months.
- 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.