| |
|
|
|
|
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 |
|
|
|
|
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 |
|
|
|
|
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:
- lines or polygons describing the extent of a patch of weeds;
- polygons describing the extent of a treatment;
- polygons defining regions or sub-regions;
- polygons defining survey areas;
- 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.
- Enter a new survey record called, for instance "Northeast addition weed survey spring 2017."
- Define the survey area with a named polygon; for instance; "Northeast addition,"
and add it to the survey record.
- Add a plant list (containing whatever weeds are expected there) to the survey.
- 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.
- 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.
|
|
|
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)
|
