Maintain, visualise, analyse records of confirmed absence

[florianm]

Problem

Maintain, visualise, analyse records of confirmed absence correctly. TSC's data model is to record "confirmed presences". Confirmed absences were never in scope, but it would make sense to support this use case.

Feature

Example for confirmed destroyed occurrence

• there's an occurrence of community X at location Z, seen a month ago (with a recorded polygon boundary let's say it was recorded in TSC),
• com X was seen at Z seen ten years ago (another polygon boundary imported from your shapefiles), and
• a recent report from today that the community X at location Z is now confirmed destroyed.
• This use case needs a written protocol in the manual for data entry, QA, and analysis.
• Suggested protocol for data entry:
  • Do: record this as point (== buffer 0m),
  • DO NOT record a polygon,
  • DO add a note "confirmed destroyed".
• Analysis: any occurrence that has one last (by observation date) point without polygon is presumed destroyed and should be excluded.
• Front-end: should mark up occurrences "covered" by a last observation of absence (point only) somehow differently (indicating destroyed).

Example for confirmed incorrect entry

• There's a record in TSC about an occurrence of community X at location Z which is definitely incorrect.
• Do: delete the record in TSC. There's no value in keeping an incorrect record.

[alexrchapman]

Re: Example for confirmed incorrect entry

• There's a record in TSC about an occurrence of community X at location Z which is definitely incorrect.
• Do: delete the record in TSC. There's no value in keeping an incorrect record.

Often better to mark as incorrect and ‘hide’ rather than delete, so that the source of the incorrect report is found later and re-added?

[edit: remove email thread]

[florianm]

There are two use cases that TSC aims to support:

• A record is definitely wrong (as in entered in error) - delete.
• A record is probably wrong and therefore definitely not trustworthy - bump QA level down. E.g.
  • A trusted record (QA "curated") is recognised as potentially wrong and "flagged" (as in please review)
  • A "flagged" record is fixed, now trusted, and QA'd to "curated" (as in trustworthy)
  • A "flagged" record is not able to be fixed, and therefore QA'd to "not trusted" (not added, find me a better label).

TSC keeps a record of trust level through QA stages (django-fsm). Transitions are both logged (django-fsm-log) and restricted (django-fsm permissions using Django user groups) to trustworthy audiences (e.g. only user group "data curators" can mark a record as "curated" to say it's trustworthy).