Add interactions to species pages

i don’t think so. The observer can already do that. The problem is there is not a clear indication that copied observations are linked (though creating one might be one angle to solve this). It’s also neat to see the organisms together. I think an in-website cropping or selected zooming option is another neat feature but off topic for this one.


Selected zooming would be great! Cropping might not be a good idea, because so many photos are already low resolution – cropping would make them even lower. @charlie, I’m not sure if this is what you mean, but maybe have a clickable box around each organism in an observation, which when clicked would bring the part of the photo bound within the box out.

@tonyrebelo, my solution wasn’t intended as a solution, but instead as a stop-gap between now, when there’s no way to link observations at all, and some future point, when interactions can be easily documented. If multiple species could be tagged in a single photo, then it’d be easier to search for those observations, rather than going through 1000, 5000, 50,000 or more observations one by one, searching for interactions.

It would also have the side benefit of reducing the number of duplicate photos, which just take up space with unnecessary redundancy. For example, this observation: is completely redundant with this observation:; if I could have just tagged each fish, then the load on the database for these two observations would have been halved.


It depends how you do it. See the interactions project
e.g. all observations of Dewsticks with interactions:

click on any one: e.g.
and you can immediately see in the observation fields that it has interactions (or links) with
Passive Partner to: (Interaction):;

The idea of an interactions module is to provide a table that links these - in this case something like:
18719545 “associated with” 18719540
18719544 “associated with” 18719540
18719543 “associated with” 18719540
18719543 “eating” 18734954
18719545 “eating” 18720598

These links already exist as observation fields and can just be clicked. But unfortunately at present, cannot be simultaneously displayed and filtered.

1 Like

There is already a thread for this: Note that duplicating does not duplicate the photograph: the one instance is shared between observations.


1 Like

Yes, I have long wanted ways to properly connect observations, it would be good if it was a more general mechanism than just dedicated to interactions. Eg to connect observations of the same entity over time, or by different observers.

I don’t think it was mentioned above, but there is also a discussion of being able to label elements within the photos at


1 Like

Considering the reciprocal linking of observations (e.g. flowers <-> pollinators) a useful thing, I am running into problems when the same plant is visited by different species simultaneously.
See here the plant:
and its pollinators: One, Two, Three, Four, Five

I added Observation Fields for each insect visiting a single Field Eryngo, but not the other way round: I cannot connect my single observation of that plant to all its pollinators via the Observation Fields – Yes, in principle I might use different, redundant Fields all meaning the same thing, but that would be the exact opposite of what I would like to have, that is a reduced amount of (standardized) fields.
In this case, it would be nice to be able to list species, comma separated, in the ‘Interaction->Flower visited by’ Field and provide links via the ‘Associated Observation’ field.

You could make successive observations on the plant, each with a different interaction. Instead of trying to make one observation have 5 associations, the 5 observations would each highlight a different species interaction. You could also link the observations together as an “observation set” and perhaps even put a link to the observation set in the description.

Considering it’s one of the top voted feature requests despite being open for a long time (i.e. a moderate number of people haven’t removed their votes to vote for something else they deemed more important), and because it’s a feature staff themselves have explored, maybe we should move this from Feature Requests to General? (closing first, so people can get their votes back?)


Maybe? I suspect the community’s ability to request features and vote on them far exceeds our ability to actually implement any of them. Maybe it would be better if everyone runs out of votes and only gets to vote more by retracting votes or when work actually gets done. An infinitude of feature requests just makes it harder for us to pick and choose what to work on, and is frankly a pretty big psychological demotivator for me, personally. I would rather consider and debate a few really popular ideas than have been people constantly getting their votes back and make a huge amount of equally popular requests. One of our goals in moving to Discourse was to reduce info overload, and I’m not sure shifting topics around so people get their votes back really helps with that.


I agree, until it is actually on the drawing board and development underway, it is “top of the pile” (so to speak) as far as potential “next please” tasks to work on. The votes help hold it in that position… and it doesn’t mean that is the order of things, just an indication of what the crowd think :)

1 Like

It is also a good place to discuss work arounds and interim measures we can take and so forth.

1 Like

I agree with both this and what Ken-ichi wrote above, which is why I was disappointed the feature request I had entered (on shared observations) which at the time was the top vote getting request on the site was moved out to a non feature request category. I really do hope the forum admins will allow feature requests to stay as feature requests.

Most people understand some things are bigger and harder to do, but if it is important enough to them are willing to wait.


The staff and moderators will discuss how to treat feature requests generally, so let’s keep this particular one on topic. You could also start a new topic in Forum Feedback.

Last off-topic post, I promise! Made a topic to address this suggestion here:

1 Like

Hi! Are there news about the development of this feature? I will really appreciate it…


Has there been any more work on allowing the same observation to have multiple interacting species that can each be IDed by the iNaturalist community and the observer can choose from a list of types of interaction? That would be amazing! Thanks for all the great work you do.

1 Like

Long time lurker, first-time poster (been an iNaturalist member since 2012). I am working on some smart camera machine-learning enabled classifiers on ad hoc LoRaWAN networks for remote field deployment, for a USDA Conservation Innovation Grant project, which is open source.

Boy, it sure seems like you would be the right person to talk to about making our back-end database play nicely with existing major knowledge engineering systems.

We poached a senior engineer from Microsoft, have professors from three universities, and an excellent backend database hacker from a Medical school. We want our project to play well with iNaturalist data structures. Are you available to help us understand how we can be most compatible?


This is not possible with an API ?

You do not use sounds (animals, bats, grasshoppers, mouse(birds).
I can not find the link but an open sound system (there are several) is building one up from bat sound detectors (including backround orthoptera).
There are open systems for it.
and also one for insects but all use theire own specific recognition to prevent unesccary species which do not occur on these sstems. (Google)

just for reference, i’m thinking this is the grant project:

i sort of wonder why they want to “play well with iNaturalist data structures”? iNaturalist isn’t a data aggregator, but something like GBIF is. so it might be more important to understand how to play well with GBIF data structures, if they’re intending to send that data to an aggregator. i suppose it’s possible that the intent is to send data to iNaturalist so that they can leverage the iNaturalist computer vision (and maybe community) for species classification, but that seems like a bad workflow. so then if they needed a computer vision species classification model, then maybe it would be better to train their own. and if they wanted an iNaturalist dataset for computer vision training, the AWS open data set would be the place to look for information, i think.


Wow, this has been around for a while. I think it would be simple enough to just draw that data from filtering certain fields (e.g. Host, Host Plant, Feeding On). In my thoughts it would be more important to keep it to unique interactions, e.g. an insect on an exclusive host, rather than a bird eating any random insect. But that it is hard to filter without numerous datapoints.