so, what are the specific fields you intend to merge? i’m not following because if you already know they should be merged, you can do multiple extracts of the data and merge the data after it’s extracted.
No fields are being merged. Existing OF fields tagged with plant names are being reviewed for being also tagged “Interaction→ Visited flower of” for the appropriate plant.
Maybe it would be helpful to be explicit:
| Observation Field | Status |
|---|---|
| Interaction-> Visited Flower of | Is fine, no need to fuss |
| Nectar / Pollen delivering plant | Is fine, no need to fuss |
| Name of Associated Plant | Is a nightmare of common names, herbivory, and bug-on-leaf. Needs to be sorted |
| Associated species with names lookup | Is a nightmare of… everything. Birds on trees, two bees in photos, the plant in the background next to a plant. Really needs to be sorted or it is a lot of wasted time cleaning up after download |
| Nectar Plant | Is fine, no need to fuss |
| Host plant | A mix of actual host plant herbivory and a mishmash of flower visitations on any plant. Needs to be sorted to be useful. |
| Feeding on | A mix of predation, herbivory, and nectar feeding. Needs to be sorted. |
| Flower Plant Name (What plant was the pollinator visiting) | Is bare text, and needs to be retagged using a different field to link it to taxa |
Thanks, this is helpful. So when you say “no need to fuss” for “nectar plant”, this means that “interaction → visited flower of” would not be added to those observations?
You would extract those “nectar plant” observations to add to your spreadsheet but there would be no need to add the additional “visited flower of” observation field?
Yes. (lmao it wont let me post this without at least five characters so here is more than that)
so you’re extracting the “no fuss” and using them as/is without adding the additional OBS field for “visited flower of”. That leaves the ones labeled “nightmare”… and for these you need to review each one. You’d like to review them on iNat since iNat provides a nice way of reviewing them. If you extract them first, you’d then need to review them off-line… which is possible… but why re-invent the wheel. Why not use iNat’s mechanism coupled with the meta data tool. Yah, I get it.
It’s a shame that so many redundant observation fields need to be stored that all point to the same taxon info. But I understand what you’re doing.
Correct!
Like i said, the data exists in an imperfect system and I don’t see any easier way to do the cleanup needed to make the “nightmare” category OF useful data for understand floral visitation patterns. It is a shame that these observations people took the time to tag aren’t in use just because they chose a messy tag. I’m doing my best to try and fix that.
As to your suggestion to recode ALL plant interactions into one coherent, hierarchical structure, I salute your bravery if you are willing to take on the task, but I am soooo not able to dedicate that much time. Doing floral visits alone has already been months of work and I’m nowhere near done for my region!
Here are some of the observation fields you mentioned. These are extracted using rate limited fetching and then merged into a single column for display…
https://stockslager.github.io/iNat/observation_fields/blog_view.html?operator=merge&obs_fields=3126%2C498%2C4935%2C1711&chosen_datatypes=taxon&query=user_id%3Dchase-prairie
In order to do this, I went here (chose and ofv_datatype of taxon, and entered “user_id=chase-prairie” in the query parameters)…
https://stockslager.github.io/iNat/observation_fields/observation_fields.html?clear_cache=yes
I know it’s not really what you’re looking for, but focused on a similar issue.
Very cool! I do essentially the same thing manually, every time I run an update on my static set, I download each OF for my region (ex: this url) and then put them all together. Here’s an example project, which is mostly new-tagged spring pollinator visits:
https://docs.google.com/spreadsheets/d/1EBsqAoRJNAJoqBs8xFdNAQodtkb7fw6I3s-kggoM15Y/edit?usp=sharing
For some reason the preview says it’s a private file, it’s not!
Thank you for posting! This is a fantastic review of the plant-pollinator OFs and I will definitely be referring to this in the future.
I use nectar / pollen deliver plant because that’s what I started with. I’ve used it to look at most popular pollinator plants in my county and for monarch butterflies.
But, based on this post I will also try to use Interaction→ Visited Flower of. Cheers!
I’m a little confused by your usage of the term “tag” in your posts - can you clarify? Are you working with tags and observation fields or just observation fields? These are different things on iNat.
i relate what you mean - when i want to record associations i usually rely on what one is used in my region so far (even if unpopular sometimes) which is usually biased from local projects observation fields or something that others talked of in that context (say for mushrooms - Substrate of fungus)
There maybe better fields but I have no way of finding such easily across domains nor what non-niche fields eventually get processed by other scientists or say sites like GLoBI.
Personally, I think this is a realisable usecase for iNat or any vibecoders here (i can team up if anyone is interested) to handle with semantic language processing to cluster all and most obscure observation fields in that domain and create groups of closely related fields and then crosscheck manually and then readd a new such better OF fields via API to observations - say in your case all fields you listed can be grouped together into higher level sets as you noticed and instead of manually mapping X OF to new closest and better Y OF, it can be automated especially when easier cases where such X→Y mapping is consistent. If this new OF additions is an issue for individual users, they can already opt-out i believe? (i think most dont mind as everyone wants their observations data to have most value for researchers) or aggregator filters as @stockslager linked above is only solution.
The end tasks of each project or user maintaining their own OF is not issue as that isnt messed, but the higher level groupings created from all existing OF algorithmically can help for both upstream researchers and assosciation aggregators datasets.
Sigh. I’m not going to go back and edit my posts, but yes I have used the colloquial word “tag” as a verb to describe the act of adding information into a Observation Field, which has nothing to do with the data-encoding tool “Tags”.
If you have another shorthand verb to suggest as a replacement for saying “I utilized the Observation Field to add information”, please do share
Thanks for clarifying. “Add OF” and similar would seem to work?
loverly breakdown