Observation Field Viewer

[stockslager]

While working on the Virtual Seed Library idea, I wound up creating an observation field viewer (used to show insect activity on plants offered through the library). The viewer requires a project_id and/or user_id and a comma delimited list of obs_fields.

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

In this case, I’m also telling it to “merge” the observation fields. The reason for this is that I’ve been bad at normalizing my own data! I use all sorts of fields when I see an insect on a plant. Was it nectaring, pollinating, resting, eating, or what? What was the insect doing there? Sometimes I’m not sure and don’t really care but it’s worth noting that for whatever reason, that insect was visiting that plant.

So… it’s useful to be able to merge and un-merge the data. If I navigate to the link above and click one of the obs_field id’s at the top, it filters out everything other than observations with that one obs_field. In this case, I clicked “498 - Nectar Plant”. This allows me to see only those instances where I chose to add a secondary observation where I perceived that the insect was nectaring on a plant…

Because I’ve now filtered out everything other than that one observation field (nectar plant), I can click a plant in the “Nectar Plant” column and only see the list of insects observed nectaring on that specific plant. In this case, I’ll choose “anise hyssop”. And now I can see all the insects I’ve perceived to have been nectaring at anise hyssop…

I can then select a specific insect and only see instances of that specific insect nectaring at that specific plant. All of this data is reachable through the iNat front-end but is organized and presented differently. It’s not realistic for iNat to imagine every possible scenario for presentment of inherently customizable user defined observation fields.

** alternative presentment is like the ropes hanging off the goodyear blimp. they’re probably important for something, but they aren’t the blimp. this is the core/custom model. inat is the core engine but maybe there should be endless customized presentment based on any specific use case.

[stockslager]

Field Study use case for Observation Field Viewer…

Scenario…
Ecologist at a nature preserve asks visitors to document the roosting location of bats in a preserve. The project requires a single observation field… roost type. The roost type obs field is displayed immediately alongside each observation in the table.

https://stockslager.github.io/iNat/configurable_obs_field_table.html?project_id=219480&obs_fields=18588

---

Since the most recent observation was of a “northern little yellow-eared bat”, that user can click that species name and see each observation of that species with the “roost type” listed immediately alongside each observation without drilling down into each observation to see the contents of the OBS field.

https://stockslager.github.io/iNat/configurable_obs_field_table.html?project_id=219480&obs_fields=18588&ofv_datatype=taxon,text,numeric,date,time,datetime,dna&per_page=50&taxon_id=75219

---

The “roost type” can also be chosen from the first link above which shows all the bats observed roosting in the preserve at a particular type of roost site… in this case, a man-made structure

https://stockslager.github.io/iNat/configurable_obs_field_table.html?project_id=219480&obs_fields=18588&ofv_datatype=taxon,text,numeric,date,time,datetime,dna&per_page=50&field:Roost%20type=manmade%20structure/objects

This makes the observation field viewer a decent companion to a project being run at a nature preserve. Contributors to the project wouldn’t need to drill down into individual observations to see the observation fields captured for each observation. They’d see them alongside each observation in the table shared via the “about” or in a journal post.

[cs16-levi]

Thats really interesting! This will be useful for entomology projects used to pinpoint species preferences.

[stockslager]

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.