Suggested Changes to Geoweed/Weed Manager in the Near Future (October 2012)
 
Below are some comments and discussion about how the improvements suggested for Geoweed might be addressed in the proposed Weed Manager system.

The comments are from Robert Steers' Geoweed lunch at the October, 2012 Cal-IPC Symposium.

See also the preliminary design for the new system.

General suggestions/questions for improvements to GeoWeed:
1. Ability to record lines in addition to points and polygons.
Yes, as part of an assessment. Question: are lines an acceptable way of recording the area covered by a treatment -- for instance, if accompanied by a width in meters?
2. Could an occurrence be a line or polygon, or can it only be a point?
Conceptually, an occurrence and an assessment are very tightly bound; you can never have one without the other. For some data elements, it it difficult to decide whether they belong more appropriately in the occurrence record or in the assessment record.

As currently proposed, the occurrence record has a point (eg. the center of the patch when it was first discovered), but each assessment of that occurrence can have a line or polygon describing the extent of the patch. When you are first entering an occurrence, you are also entering the initial assessment of that occurrence, and this assessment can have a line or polygon.

3. Fields need to be auto-populated when possible to save time (e.g. time, date, region, etc.).*
None of these fields need to be entered. Time and date can come from the entry device. Region can be inferred from coordinates.
4. Desire to have a comments/notes field to capture info specific to an organization [there already is a notes section - could be modified].
As proposed, the new system will allow each organization to specify their own sets of extra fields to be included in various tables (occurrence, assessment, and treatment). Each extra field can be either optional or required.
5. Would be good to be able to specify the type of work (was this for a restoration project, ED survey, focused survey, etc…). Clearer project specifications or Project ID linked to each Occurrence, Assessment, Treatment, and Survey.
As proposed, the new system has a project table just for this purpose.
6. In a shared database we need to be able to view/upload data for individual or multiple projects (& users).
The new system will have various ways of getting datasets in and out (along the same lines as Calflora's Upload and Download data web applications). The Search for Weed Data application is like Observation Hotline, but will have the ability to search for records by project.
7. Need enterprise-level protections for sensitive data.
As proposed, data in the new system will be, by default, completely private to a group (organization).
8. Option for users with MyCalflora accounts to create customizable fields in addition to core GeoWeed fields that will not be editable.
See 4. above. As proposed, certain tables in the new system are extensible, but only on the organization level, not on the individual level.
9. Need custom data dictionaries by project ID or user account (or both), so you don't have to scroll through a bunch of unused fields, and are not required to fill-out fields you don't use.
See 4. and 8. above.
10. Need to be able to turn-off or hide fields that you do not want to use to keep data collection as simple and efficient as possible.
This is the intention of the new system. The idea is that the decision about exacly which fields to show or require is made by an organization administrator when a project is set up.
11. Need a field for land ownership
It is part of an occurrence record.
12. Include field(s) required for EPMT (NPS) reporting.
See 4. and 8. above.
13. Reporting functions are limited; few options available to generate reports. Needs improvement.
Reporting capabilities should be an ongoing discussion.
14. Photos feature seems useful but not sure how easy it is to use?
15. A data management protocol is needed.
Please see the section on Record Ownership in the design document.
16. Can we upload historic ArcGis data into GeoWeed/Calflora? This is a "must-have."
Yes; see 6. above.
17. Terra Sync has advantages over Arcpad (less buggy). It would be great if new system worked on multiple platforms (TerraSync, Arcpad, Android, iphone).
This is a strategic direction for the new system.
18. If we just eliminate the Geoweed toolbar, and make Geoweed into a set of data dictionaries, then could it run on Arcpad & TerraSync?
Unknown.
19. Add a buffer points feature to enhance rapid-assessment capability. This is what they use at YOSE. People will use it if it is quick and uncomplicated.
This is possible as an extension to an assessment record.
20. The need to make separate points, polygon assessments, and polygon treatments (in that order) is not time efficient. It would be good to both have the ability to begin with an assessment that auto-generates a point at its centroid, or begin with a point that automatically buffers a polygon around itself.
The new system should be able to accomodate short cut methods like this.
21. Field personnel rarely have time to walk the perimeter of a polygon. Ability to do quick heads-up digitizing is valuable. Tablets would be great for this.
Ideally the system would let you either 1. walk the perimeter of a patch with an entry device to describe a polygon, or 2. let you enter a polygon on top of an aerial photo, either on a tablet in the field or on a computer back in the office.
22. People want something simple and efficient. Land managers tracking treatments are primarily concerned with time efficiency in the field, maximizing treatment time and minimizing mapping time. Mapping is often done afterwards in the office. How do we improve GeoWeed to the point that people prefer to map in the field?
This could work if there was a decent tablet application that uploaded directly into the system.
23. Send quarterly or biennial reminders to upload data to Calflora if using GeoWeed offline.
Specific Changes to Occurrences:
101. Many of these fields should be automatically populated.
Yes; see 3. above.
Specific Changes to Assessments:
201. Assessment module should not contain treatment info (e.g. bags removed). This info should be in Treatments.
Yes; in the new system, for instance, quantity of material removed might be an extra field in a treatment event record.
202. Not sure how to record something is extremely widespread (virtually or nearly ubiquitous).
This needs further discussion.
203. Ability to record that while the map shows only a specific patch, plant is actually widespread or ubiquitous. Could be a note field.
204. Polygons need to be distinguishable by year (color-coded?).
Yes; the Search for Weed Data app should be able to do this.
205. Distance from water: more info needed on type of water feature.
206. Distance from water: If one is working near water -- say mapping pepperweed -- "distance from water" doesn't do it. Consider aquatic, brackish, salt, riparian, top of bank, above or below mean high tide (or similar; you need to define this because it can be confusing -- e.g. do you mean some extends lower, or most, or what?), exposed to waves or currents.
Yes; see 4. and 8. above.
207. Plant Density: should not have to specify the "per Area" field (e.g. Sq. feet, sq. m, Ha. Acre, etc…) the density should be based on the polygon mapped. This field could be removed.
As proposed, the new system has number of plants and distribution (following BAEDN). If the user supplies a polygon, then gross area could be derived from it.
208. Cover Class: some prefer more cover classes, others prefer the same number of cover classes but different breaks, while others do not like cover classes and would prefer if you could just enter the % cover straight-up.
The set of cover classes are something that an organization administrator would determine when a project is set up.
209. Distribution: needs description for isolated, linear, etc…
210. Distribution: add "patchy" and scattered patchy"
An organization administrator would determine this when a project is set up.
211. Associated Vegetation: could replace this with a drop-down where you select the top 3 associated species.
If this field is needed, it is probably more appropriately included in a occurrence (describing the nature of the location) rather than in an assessment. The set of values are something that an organization could determine when it sets up its instance of the system.
212. Associated Vegetation: what about emergent or aquatic vegetation?
213. Associated Vegetation: need more "urban mix" options (paved roadside, dirt road side, horticultural landscape, highly managed lawn, landscaping, urban mix on hillside, etc…).
Specific Changes to Treatments:
301. Can a treatment apply to multiple occurrences? [yes]
Yes; multiple occurrences and also possibly multiple different weeds.
302. For treatments (and applicable to assessments), colors of polygons should be different. Could choose colors based on year made, recorder, species, project ID, etc… Right now, in places where many treatments have been made (e.g. a small restoration site), it becomes difficult to tell apart or select the different treatment polygons.
Yes; see 204. above. The Search for Weed Data will do this.
303. Treatments need to be more easily linked to the assessments, preferably by including a field with the species name.
304. Initial mapping and assessment works well, but as treatment progresses through time and the population becomes fragmented, it becomes too time consuming to map each separate patch. It is also unclear how to map separate patches that have become fragmented from an initial large patch (i.e. you could start with one assessment for a large patch which turns into many small patches after treatment). It needs to be easier to link these new small patches to the initial large patch using GeoWeed (yet, also be able to clearly separate them visually on the GPS and GIS as has been indicated by previous comments).
As proposed, the new system provides a root record ID field in an observation record to provide for this case. When an original large patch becomes fragmented by treatment into many smaller patches, a new record can be entered for each of the smaller patches, with root record ID set to the observation ID of the original patch.