Details
-
Bug
-
Resolution: Fixed
-
Low
Description
Based on a recent meeting of Team Awesome (minus Gary) held on 2019.02.14
Action key:
```
Action | Meaning
Keep. | no action
X. | drop
+. | add
? | TBD
-> | rename
```
```
Column Action
obs_id Keep.
dataset_id Keep.
loc_id Keep.
taxon_id Keep.
observer Keep.
obsdate Keep.
d_detection_circumstance_id Keep.
absent_ind Keep.
d_tax_eval_change_reason_id Rename?
Slightly deceptive title. This column is
meant to connote why a "taxon_id" was
(re)assigned from what was originally found
in the input. Per the description of the
default row this column references, the
current default actually makes very little
sense.
confidence_notes -> eval_comments
d_tax_confidence_id X.
Several different values are set in this
column across different observations,
meaning it's likely been semi-manually
populated during upload. Notes should be
migrated to eval_comments.
tax_confidence_by X.
tax_confidence_date X.
tax_conflict_ind -> sys_tax_conflict_ind
tax_conflict_notes X.
loc_description Keep.
d_mapping_confidence_id X.
mapping_confidence_by X.
mapping_confidence_date X.
mapping_conflict_ind Keep.
There appear to be no human-set flags in
this column:
SELECT COUNT
FROM observation WHERE
mapping_conflict_ind
AND (
mapping_conflict_notes
NOT LIKE 'Possible issue%'
);
mapping_conflict_notes Keep.
There appear to be no human-set notes in
this column, as only system-messages are
reflected when searching on unique values:
SELECT DISTINCT mapping_conflict_notes
FROM observation;
d_range_confidence_id X.
range_confidence_by X.
range_confidence_date X.
range_life_history_conflict_ind -> sys_range_life_history_conflict_ind
range_detectability_conflict_ind -> sys_range_detectability_conflict_ind
range_occurrence_conflict_ind -> sys_range_occurrence_conflict_ind
range_conflict_notes X.
There appear to be no human-set notes in
this column, as only system-messages are
reflected when searching on unique values.
obsdate_daterange Keep.
d_obsdate_confidence_id X.
Several different values are set in this
column across different observations,
meaning it's likely been semi-manually
populated during upload. Notes should be
migrated to eval_comments.
obsdate_confidence_by X.
obsdate_confidence_date X.
obsdate_error Keep.
obsdate_conflict_ind -> sys_obsdate_conflict_ind
There appear to be no human-set flags in
this column.
obsdate_conflict_notes X.
There appear to be no human-set notes in
this column, as only system-messages are
reflected when searching on unique values.
observer_notes X.
This column has only ever been used to
echo the contents of the WOS "Observer
Activity" field, which is also expressed in
`obs_code_link`. No information will be lost
as a result of dropping this column.
Though WOS was intended to write an
observer's field-notes to this column, this
was never set up. "obs_comments" will be
used instead.
habitat_description Keep.
d_habitat_confidence_id X.
habitat_confidence_by X.
habitat_confidence_date X.
habitat_conflict_ind X.
No observations currently have this flag
set. If it is determined at a later date
that it's useful to automatically overlay
landcover or other habitat-related layers
with observation-points, we can add a
similar column back to this table.
habitat_conflict_notes X.
There appear to be no human-set notes in
this column.
obs_comments Field notes from observer(s) should be
stored here.
internal_notes Keep.
created_date Keep.
created_by Keep.
modified_date Keep.
modified_by Keep.
d_sensitivity_sunset_id Keep.
d_land_ownership_detail_id Keep.
eval_fail_ind Keep.
Note that certain records may fail
evaluation (per database folk) before a
biologist looks. Reason for failure (or a
pass despite system-set flags) should
generally be noted regardless of whether
it's a biologist commenting or not.
Constraints could be written to enforce
these things.
system_conflict_notes -> sys_conflict_comments.
Keys should be tweaked in trigger-code to
reflect the nature of the conflict in
addition to the source obs-detail (if any)
e.g. 'obs_tally 1734 life_history' and/or
'obs_tally 1734 value' instead of just
'obs_tally 1734'.
Main comments should appear similarly as
'main occurrence', 'main detectability',
etc.
eval_date +.
Needs some WHEN-guarded triggers to set
when eval_* fields are touched.
eval_by +.
This should be a `person_org_link`
reference and will need some logic attached
to it to make sure it actually indicates a
biologist's link when "biol_eval_ind" is
true; database folk need not apply.
This should indicate the last reviewer who
looked at the record IN ITS ENTIRETY.
biol_eval_ind +.
Indicates whether a biologist reviewed the
record or not. Column-comments should
indicate that records not be partially
reviewed such that mixed "eval_by" values or
such things would be needed structurally.
user_conflict_response +.
Separately captures a user's response to
system-flags. In some cases this user may
be the original observer, but this may also
be a third party merely in charge of input,
who may just place contact-information
here. Collection of such responses is not
mandatory, but may be helpful for adjusting
range-maps or evaluating individual
observations.
```
Also see email from Melanie dated 10/4.2016 with subject heading: "some changes to observation table based on my experiences thus far"