Hey everyone, I’ve noticed on a few observations recently that withdrawn IDs still count against community taxon consensus.
For example, on this luna moth I suggested the wrong silkworm group, noticed and corrected immediately, but the community taxon is still showing a disagreement.
https://www.inaturalist.org/observations/55498872
For this observation of course it doesn’t matter, but for one with less IDs it might.
Or has this always been a thing and I just never noticed?
There’s an open bug report on Github for this here: https://github.com/inaturalist/inaturalist/issues/2656
Thankfully it’s not actually counting “against” the community taxon though (otherwise it would need one more ID to flip to Actias luna - >2/3 agreement).
Please fill out the following sections to the best of your ability, it will help us investigate bugs if we have this information at the outset. Screenshots are especially helpful, so please provide those if you can.
Platform Website
App version number, if a mobile app issue (shown under Settings):
Browser, if a website issue Firefox
URLs (aka web addresses) of any relevant observations or pages: https://www.inaturalist.org/observations/57024629
Screenshots of what you are seeing (instructions for taking a screenshot on computers and mobile devices:
):Description of problem (please provide a set of steps we can use to replicate the issue, and make as many as you need.):
Step 1: Why is there still a red mark if there are no more contradictions between IDs?
Step 2:
Step 3:
Потому что disagreement работает против, хотя по логике и не противоречит более точным определениям, есть несколько топиков по этой теме, мне сейчас с телефона сложно найти.
This is a known bug, I’ve moved your post to the relevant topic.
Discussion also here: https://forum.inaturalist.org/t/community-id-display-confusing-neutral-ids-display-as-disagreement/12744
Platform (Website):
Browser, i( Chrome) :
URLs (https://www.inaturalist.org/observations/93700485)
Description of problem
ID to Paranomus x 1 and Paranomus esterhuyseniae X 2, but community ID box reports two green and one red (disagreeing) ID.
About reports correctly:
The community taxon (or community identification) represents …
…
|Subtribe Leucadendrinae Cape Nutseed Proteoids|0|3|0|0|3 / (3+0+0=3) = 1|
|Genus Paranomus Sceptres|1|3|0|0|3 / (3+0+0=3) = 1|
|Paranomus esterhuyseniae Kouga Sceptre|2|2|0|0|2 / (2+0+0=2) = 1|
So just the index bar is the issue.
(moved to existing report)
On this observation https://www.inaturalist.org/observations/94660886
The community ID is correct, and the algorithm calculates correctly. However, the graph is incorrect as it shows a red bar for my ID of Family Gekkonidae. This was a disagreement with the original ID of Brown Anole (not in Gekkonidae) but does not conflict with the current Community ID (Hemidactylus garnotti), which is a gekko.
This seems to be related to some other reported issues with the Community ID graph displaying incorrectly.
I merged this one to the existing bug report. Looks like the issue on github is still open.
is this more of the same bug or different? my ID of genus proceratium is disagreeing with the above ID of subfamily myrmicinae (since proceratum is in subfamily proceratiinae), but not with the species level community taxon of proceratium siliceum
so we have a wrong subfamily ID, then a correct genus ID, then 4 agreeing species IDs in that genus, yet 2 red bars are displayed on the community taxon, it looks like any ID that is a “dissagree” displayes a red bar, even if it agrees with community taxon
But is only does that when the disagree is less specific, here the same thing happened but only the dissagree that is at genus level is red, and not the species level one
Platform: Web
Browser, if a website issue: Chrome, but not browser-dependent.
URLs (aka web addresses) of any relevant observations or pages: https://www.inaturalist.org/observations/37948399
Screenshots of what you are seeing:
Description of problem:
Step 1: Open an observation with multiple IDs where at least one “improving” ID was in disagreement with an earlier ID that was later withdrawn. In this case tansh91’s improving ID of Burmannia disagreed with ryruther’s original (now replaced) ID of Orchidaceae.
Step 2: Look at the Community Taxon section to the right. It shows the correct community taxon of Burmannia longifolia based on three species-level IDs and three IDs for the genus Burmannia. Note that none of these IDs disagree with the community taxon. Click the About button and you will also see that there are no disagreeing IDs.
Step 3: Look at the “Cumulative IDs” graphic and explanation just below the Community Taxon name. This states “Cumulative IDs: 5 of 6” and shows a bar-style graphic with 5 green segments and 1 red one. The clear implication here is that one of the six IDs disagrees with the Community Taxon. I assume this must be a holdover from an earlier state where the observation did have disagreeing IDs. Perhaps the logic that recalculates the CID does not update these fields?
I have not validated this with other observations. However, I did attempt to trigger a refresh by toggling DQA items and the observation is unchanged.
(merged with existing report)
Thanks for merging this @jwidness . I’m not sure whether I should be happy that this is a known issue that just affects the UI but not the actual community taxon, or sad that the bug remains unfixed five years after it was reported and (apparently) four years after the last time anyone tried to fix it.
I’m a little surprised I didn’t notice this bug earlier.
Doesn’t update the index bar might / would explain obs I have tripped over.
Random example which is confusing. RG at sp. Index bar displays as 5 of 6 to sp. But it is actually 3 right against 1 wrong for sp. 5 of 6 in fact agree at Family.
Surely the index bar, and the table for the algorithm, should agree with each other.
Same issue, my Subfamily Halictinae ID disagrees with a now-withdrawn ID, but agrees with subgenus Dialictus community taxon, yet still shows as disagreement and has red bar: https://www.inaturalist.org/observations/308286419
This is fixed now.
