Description of need:
Users routinely duplicate observations for multiple species - diligent users routinely add links to all others, but iNat can automate that with auto-adding parent ID observation to above popular observation field. It will aid both IDers better to associate interactions when IDing the duplicated observation (instead of going to their profile and searching for other observation if its not linked manually) and knowing what they want to be IDed in duplicated one ā¦ It is also a valuable datapoint for future taxa associations analysis research so even when users forget to link those - auto-linking will help.
Maybe others can comment if there are negative caveats for such automation above. Or it can be some setting where users can opt-in/out too if there are caveats.
Feature request details:
When users click duplicate option on app or mobile, auto-populate and link the parent observation url with the above field for new observations.
iām not sure that using an observation field to link observations is the best way to handle the situation. observation fields are meant to handle custom user needs. so if youāre going to modify the system to do something, you should just add system functionality for that, not try to leverage an observation field.
when you duplicate a photo before itās been fully uploaded via the web uploader, you can actually end up with two different photo records.
when you duplicate an observation on the Android app, you also end up with new photo records. (i donāt think it has to be that way, but thatās the way it worked the last time i checked.) iām not sure about what happens in the other apps.
This is a duplicated shell record (by using duplicate option on iNat) from hermit crab observation - and there is no assosciation here anywhere unless user explicitly mentions or adds fields:
One temporary solution could be to use the API to automatically find observations sharing photos and then appending the corresponding ids to some specified observation field for the relevant observations. The API is described in detail at https://api.inaturalist.org/v1/docs/ and I donāt think it should be too hard to āvibe codeā such an application in python
If the photos are similar but not duplicated by iNaturalist (i.e., they have different ids but are exact copies), we will have to add perceptual hashing or another algorithm to find duplicates (and preferably caching since we then need the actual image data), and then use these to automatically populate a specified observation field
on sidenote maybe perpetual hashing should be eventually considered to also handle copyright issues (i have seen users uploading others old observations photos) and flagged hashes can keep track where past such flags have been resolved by curators. although ofc there is always ways to circumvent such hashing too, such hashing can aid curators atleast.
ā
and ofc its not hard to use API and automate such fields, but I only want to highlight iNat as platform linking assosciations is better equipped and since I dont know there is photo ID sharing already - and if photos share IDs upon duplication consistently then this request is not big of a deal. Can we close feature request threads?
well i guess we cant file bug report too here, as the new inat next app is priority now for devs. maybe we can revisit depending on how iNat next handles things for consistency.
I agree with the intent of this and sometimes wish there were more thought put into this specific issue. I think the difficulty here might beā¦ what happens when the parent observation is deleted?
The interactions OBS fields refer to a taxonā¦ a taxon that wouldnāt be deleted (or is less likely to be). The problem isā¦ storing that taxon data with every (in many cases) hierarchical interactions leads to the Garald-ification of any observation of an interacition. Why store the taxon every single time?
Example hierarchyā¦
name of associated plant
āinteraction ā visited flower of
āānectar / pollen delivering plant
āāānectar plant
āāāpollen delivering plant
These hierarchies are the only way to capture all the information for the interaction that satisfies the aggregate (what taxon was the observed taxon on? And the granularā¦ (what taxon was the observed taxon executing this particular interaction with)?
If a āfound onā taxon were collected as a ācoreā iNat observation field (like annotations that are always available to be captured)ā¦ the interactions could be captured in a drop-down list of simple name/value pairs (or better yetā¦ a multi-select). This is because the people only interested in the granular would be asked to capture the āfound onā before choosing the more granular interaction.
As it stands, the above hierarchy would be modeled by storing all the data for a single redundant taxon five times on that observation. These five mirrored instances of the taxon data would then be returned by the observations endpoint up to 200 times. At least thatās my understanding.
The other way would be to only return the field_id and field_name for the observation fields of type taxon that have matching values. it would break a lot of downstream logic but could be an option with a default on the API interface.
not really. I see the comment as related. but I can move or delete if it isnāt. actually, now that I re-read itā¦ this is something different youāre talking about. I donāt think I can move it, but someone else can if they want. it does apply better to the other thread. sry.