Observation Field Viewer

Use Case ~ Normalizing Interactions Data at a Nature Preserve

Scenario…
Visitors to a nature preserve have chosen to use all sorts of different observation fields when an insect has been observed visiting a plant. The preserve would like to make it easier to search and filter these interactions but the inconsistency in the observation field data makes it difficult.

They can use the viewer without passing in any obs_fields while specifying

&project_id=133007 // the project Id for the nature preserve’s biodiversity project
&iconic_taxa=insects // the iconic taxa whose observation fields they’d like to normalize
&ofv_datatype=taxon // the data type of the observation field
&operator=merge // telling it to merge the OBS fields if there are eventually more than one

The viewer would show all insect observations that have an observation field of type taxon…

https://stockslager.github.io/iNat/configurable_obs_field_table.html?project_id=133007&iconic_taxa=insecta&ofv_datatype=taxon&operator=merge

If they click the OBS photo for the first observation in the list, they can see that observation in inat and also see the observation field used for that observation… “plant that the organism was found on” (7623). This observation field is added to the obs_fields param in the url (&obs_fields=7623).

The viewer would show the contents of that observation field for any observation that uses 7623 (plant that the org was found on).

https://stockslager.github.io/iNat/configurable_obs_field_table.html?project_id=133007&iconic_taxa=insecta&ofv_datatype=taxon&operator=merge&obs_fields=7623

Scrolling down through the list, some of the rows don’t have a plant name populated because a different field was used.

Clicking the OBS photo and looking at the inat observation for the first one shows that the 498 - Nectar Plant observation field was used. 498 is then added to the obs_fields param…

https://stockslager.github.io/iNat/configurable_obs_field_table.html?project_id=133007&iconic_taxa=insecta&ofv_datatype=taxon&operator=merge&obs_fields=7623,498

If the entire table is scrolled… looking for blanks and adding the observation fields for those observations, the nature preserve has a consolidated list of all insect visitations to plants.
https://stockslager.github.io/iNat/configurable_obs_field_table.html?project_id=133007&iconic_taxa=insecta&obs_fields=7623,498,4935,7807,254,1711&ofield_iconic=47126&ofv_datatype=taxon&operator=merge

This also allows them to see which observation fields are thinly used within the preserve and which observation fields might be synonymous with other observation fields. Allowing them to suggest to visitors the use of consistent fields for capturing “insect on plant” data. This could be done by simply linking to the observation field viewer from their biodiversity inat project for that preserve. Most observers would probably want to be on the list… and would use the obs fields that would trigger their observations to appear there.

If the preserve added “plant that the organism was found on” to the observations using “nectar plant” it might seem redundant, but would allow filtration based on insect name and plant name since the data in the table wouldn’t need to be merged… https://stockslager.github.io/iNat/configurable_obs_field_table.html?project_id=133007&iconic_taxa=insecta&ofv_datatype=taxon&obs_fields=7623

Nectaring, pollinating, and eating are somewhat mutually exclusive. In each case, the insect was visiting the plant (albeit with different intentions). They’re somewhat hierarchical. Each preserve might look at them differently but normalization of the data within the preserve might give human visitors a richer experience. They’d more easily see how data they’ve collected fits in with data collected by other observers.