Easy way to mark multiple-species observations

It seems that we could figure this out in a progressive manner:

  1. First iNat adopts @jeanphilippeb’s suggestion to add a DQA field for “Images are of the same individual(s)”. That allows us to identify problematic observations.
  2. Ideally at the same time, iNat adds functionality to notify observers when their observation is assessed as not being a single individual/species, along with some guided approach to resolving the issue. That allows observers to understand and fix the problem.
  3. After this has been in place for some time, iNat staff could then do some data analysis to see:
    a. What proportion of “multiple” observations are fixed by the observer? (Probably should focus on stats for observations made after the new functionality is added; for earlier observations there’s a much higher chance the observer left iNat already).
    b. What are the stats for image count, location and date-time for unfixed observations: e.g. how many observations have 2, 3, 4, etc. images; how many have location/date-time metadata in the images; when metadata is present, what’s the spread of location/date-time data among the images?

With that info, we would be better informed to decide what kind of auto-split policy could reliably avoid exposing private data. For example, we might find that among unfixed “multiple” observations where all images have metadata, 91% have timestamps within 30 minutes and locations within 250 m of the data in the iNat record. It might be determined that those criteria are restrictive enough to infer that the location privacy settings from the original observation can be applied while creating new observations.

We might then determine additional rules for auto-splitting observations that don’t reach that threshold. For example, the newly created “child” observations might derive their time and location from the image metadata but be set from the outset to have the location obscured.

I think we can start with tools to help users and the iNat community address the problem and later assess what automated fixes could be safely made.


This has the potential to impact hundreds of thousands if not millions of observations from people who add multiple photos of the same species into a single record from their outings.

While I understand the well debated rule is ‘one observation = one individual’, do we really want this hard enforced?

1 Like

Why do you see this first step as having such a large impact?

The first step just provides one more DQA field. No records are changed. iNat users can then choose to assess an observation as not being of a single individual in the same way they can currently assess an observation as being not wild or having a suspect location.

The impact would merely be that we’d have a way to trigger notifications to the user to alert them to the issue and help them fix it. And that we’d be able to easily filter out content from these observations (e.g. photos) and prevent them from erroneously appearing in search results.

What is the scenario that you feel would be a problem for this first step of the proposed change?


It’d be pretty hard to hard-enforce for many cases (I have had cases where I honestly don’t even know if the several photos of the same species of bird from the same tree are the same individual or another one from the group, etc), although I’d imagine if the observation is also not from the same approximate location, just the same field trip, then we would actually want to start enforcing it or the location becomes kinda meaningless? (plus, it’s IMO very interesting data to have 10 obs of the same species rather than one, it shows how common it is…)

I am questioning the need/appropriateness of flagging records with multiple photos of individuals of the same species in a single observation as is apparently being suggested. Not cases with clearly different species.

All it will take is a few retentive hyper rules oriented people to start flagging such records to create a lot of disquiet.


Yeah, I think multiple individuals seen in the same area at the same time are not any kind of issue at all. Personally, I only care when it’s wildly different species all lumped together.


Personally, I’m not suggesting that we flag observations with multiple photos of individuals of the same species. I’m focused on the very common scenario where a newer iNat user creates an observation with separate photos of a squirrel, a mushroom and a rose. If the community feels the right text for a DQA field is not “Images are of the same individual(s)” then I’m very happy for iNat to use a better description of the issue.

The much narrower issue about whether five photos of various warblers in a tree are all the same species is not the same. That issue is probably handled quite manageably through the current ID and comment tools.


This should not be an issue at all, nor should it even generate a comment. As long as the species identified by the observer / identifier is present in the photo, it is irrelevant if there are other, even more numerous individuals of other species also shown.


Great! Are you in support of the proposal to add a DQA field that addresses the squirrel/mushroom/rose issue?


I have no objection to it so long as it is very clearly for that use case only. Not for different individuals of the same species, not for there is another species on the photo as well and I want the record to be for that instead etc.


I like your thinking here. We should consider the wording a little more I think, since Multiple species could also be interpreted as applying to a single photograph, which is not the problem being addressed here. So for a DQA, maybe something like

Same species in each photo    :+1:   :-1:

When there is a single (or no) photo, this should be greyed out and all votes cleared. This wording also addresses @cmcheatle’s concern about photos containing different (and/or multiple) individuals of the same species/place/date, which is discouraged but not strictly enforced on the site.

I think we also need to think about follow-up. Consider the diligent new iNatter who gets 5 downvotes and quickly fixes the problem, splitting their multiple species into separate observations. They only get one upvote to counter the 5 downvotes on their original observation. What’s the chance that enough of the downvoters will then come back to change their votes?

My suggestion: When number of photos on an observation decreases, the DQA is automatically cleared and reset by the system. If it turns out to have been only a partial fix, people can downvote the DQA again until the fix is complete.

Or as a workaround, I suppose the observer can just delete their original observation and re-post it with a single species.


Location can be exceptionally important - in the cases of plants as an example, and also can be absolutely acceptable at larger ranges (that’s what the accuracy buffer is for). If I see bird species x in my local park, and then see another one 100 meters down the trail, it serves no purpose to enter multiple records indicating that. Tomorrow the birds could be 5 meters away, or 200 meters away. What is relevant is that they are in that park.

Abundance is a critical datapoint, the refusal of the site to implement a standard way of tracking it is one of my 2 biggest, most consistent points of frustration with the site. But I’m not sure recording multiple records for every individual is the best approach. To begin with it puts the iNat data out of step with most other platforms which track numbers of individuals seen within the context of a single record. Thus iNat data becomes harder to share or integrate. It also leads to needless flooding of the site with records to identify etc.

As an example (we’ll see how long it takes me to get flagged or comments they are duplicates etc). To strictly follow the rules I just did this :


Surely it is better to put in one record that says I saw 6 of them, or even more accurately that says I actually saw 25, but was able to photograph 6


Oh, I didn’t mean that, I probably just misunderstood your “people who add multiple photos of the same species into a single record from their outings” comment as “if they take 20 pics on the same walk at different times, they upload them all into one observation”. If you meant “don’t create one observation per organism of the same species on a photo”, then yeah, that’s probably overkill in most cases, unless each one is very significant for some reason (different banded birds maybe?).

1 Like

Yes, or different levels of molting, life stage, sex, color, etc…

That should be solved if/when photo level annotations replace or are added to observation level annotations.

1 Like

Molting, wing color, and thousands of other observation fields and data types aren’t annotations, and many observations are added to projects based on this type of information, but not annotated.

It’ll be interesting to see how a future photo annotation feature is implemented, whenever that is, and it would be helpful to know if that feature is intended to change the current definition of what an observation is, or if it would only be used for indicating in a photo which individual is the female, for example, or which part of the photo is depicting the fruit.

Anyway, it’s difficult to discuss topics ancillary to a feature that doesn’t exist…

I still would prefer a more inclusive option:

1 Like

all photos show the single chosen species

The followup - since the original has no ID - force new obs for each species? Good practice in the beginning when everything about iNat is confusing. And encouraging for new people if - instead of the multiples being ignored, they get the multiple engagement and IDs.

If iNat blocks the option to ID multiples
4 – Comments and ID box greyed out. Replaced with a kind and helpful toast, with a link to a tutorial showing how to - split into species, make new obs, delete the problem child.

Very much hope for an elegant solution before the bio-blitz next April, as this year’s has left some dormant confusion. @tonyrebelo


Yes, yes and yes. A DQA field labelled something like “Same species in each photo” or “Same species in all photos” limits the confusion over how “Same individual(s)” might be interpreted. (It’s a pity that “species” is ambiguous as to singular or plural, but I think other options such as “taxon” are more confusing.)

Totally agree that this DQA field should only be available for observations with multiple photos. And any edit that removes an image should reset this DQA field. As @jdmore says, the small proportion of observations that are still problematic can just be DQA’ed again.


I just copied/pasted “Images are of the same individual(s)” from someone else input.
But I meant “Images are of the same species”.

Observations showing different individuals of the same species should be allowed, provided that the location is approximately the same, otherwise separate observations would have more added value. Multi-individual observations may show variations, and reduce the flow of observations.

I can’t advise about the precise syntax/wording (not native English speaker).

In the first place, we need to fix and agree on the specification (that the DQA label will summarize):
Each photo [or sound record] in the observation must show [something of] an individual of [likely] the same species.

Remark 1:
This species may not be uniquely defined. An observation with 2 pictures, each showing a butterfly on a flower, will not be flagged if either the butterflies or the flowers are of the same species.

The question whether to ID the butterfly or the flower is different. But if identifiers start to ID the butterfly in the 1st picture, of a different species from the butterfly in the 2nd picture, then the flag should be set. If we ID the flowers (that happen to be of the same species), then the flag is not set.

Remark 2:
An observation showing different Fabaceae species in different pictures can be IDed as “Fabaceae”, but we should encourage a split. In this case the flag is set. Therefore, the DQA field label must mean species, not taxon.


Multiple-species observation unlikely to be solved without a new DQA field: