Observations of some genera of Nerioidea appearing while searching for Diopsoidea

Platform: Website

Browser: Microsoft Edge (but checked by @zdanko too)

URLs (aka web addresses) of any relevant observations or pages:
https://www.inaturalist.org/observations?place_id=any&taxon_id=774573&view=species, https://www.inaturalist.org/observations?place_id=any&taxon_id=603713&view=species

Screenshots of what you are seeing:

Description of problem:
While searching for observations of Diopsoidea, for example, 8 observations of Tanypeza longimana (Nerioidea) appear.
If I search for Nerioidea, 11 observations of the same species appear.
If I search for the species, 19 observations appear.
I checked other genera and species of Nerioidea and checked this happening in Neotanypeza and Strongylophthalmyia too, and another species of Tanypeza.

I think I saw another post about this a while back that either got ignored or solved, but I can’t find it and can’t remember what happened in the end, so hopefully someone else has an idea.

1 Like

There was probably an ancestor change that didn’t get all the way through the system. It will also happen with taxon swaps. Usually inactivating and reactivating the taxa fixes things, but I’ve tried that for the following taxa and nothing has changed yet:

  • Tanypeza longimana
  • T. picticornis
  • Neotanypeza
  • N. ornatipes
  • Strongylophthalmyia ustulata

A quick way to check if this worked is that the total species should be 79 instead of 83.

I’m seeing 16.

cf. https://forum.inaturalist.org/t/some-taxa-not-being-classified-according-to-higher-taxa/23940

3 Likes

These are all fixed—at least they’re not showing up under an Explore search for Diopsoidea. However, Tanypeza and Strongylophthalmyia have now showed up so I’ll go and do the same thing for them (after inactivating all the species first).

I’ve never seen genera show up after species disappeared, so I guess this isn’t quite correct. But we’re at 81 now which is expected.

2 Likes

OK looks updated now! Down to 79. Looks like it takes about 2 hours to update. Let me know if there’s any other problematic taxa. You can also flag them to bring them to the attention of curators.

3 Likes

Thanks for the help! Seems like it’s everything right now.
I actually reported this as a flag initially, but @zdanko told me to post it here.

1 Like

I have a similar problem when searching for observations of Chrysomeloidea (specifically observations in the Eastern United States, as there are too many species observed worldwide to be able to see them all at once, but I imagine it’s not a locality related problem). There are at least 50 species, subgenus, or genus level taxa in Cerambycoidea (specifically Cerambycidae) that are shown along with all the observed taxa in Chrysomeloidea. When I click on the “1 observation” for, let’s say, subgenus Prionus (in Cerambycidae) it shows me all 3,832 observations of 4 species in that subgenus in the Eastern United States.
Should I post this separately as a bug report (or beetle report, haha), or flag any of the taxa, or do I not need to?

We don’t need another bug report. It might be helpful to have all of the current reports merged and renamed because it’s the same issue. Flagging taxa as needing to be refreshed would probably work best.

As for this issue, inactivating and reactivating is unrealistic because this process involves inactivating any children first. When dealing with large insect genera and families, that’s just not practical.

Luckily, I’ve found a much better solution: edit something else and save the taxon (tried for Sybra, Moechotypa, Centrodera, Sternidius, Anelaphus, Pterolophia, and Anomophysis). The best thing I found is to make an edit (such as turning off the Wikipedia link), but then you have to go back in and change it back. It also works in a matter of minutes instead of hours, but taxa with more listed observations take longer.

Maybe there’s a way where nothing has to be undone and it only takes one iteration of “edit, save”. Refreshing the parent or Wikipedia links doesn’t work though.

Note, I’m using lrank=complex to view the problematic (sub)genera.
https://www.inaturalist.org/observations?subview=map&view=species&taxon_id=176269&lrank=complex (currently seeing 922 “species”)
I’m wondering if there’s a way to search for observations in mutually exclusive groups, which shouldn’t happen, but is what’s happening here. This doesn’t work though:
https://www.inaturalist.org/observations?subview=map&view=species&taxon_id=176269,47961
Such a search would be helpful for finding out of place taxa. I can mostly pick out cerambycids from chrysomelids from the taxon photos, but it would be nice to not have to look through 900+ pictures (only 500 at a time I suppose though).

As for the difference in observation numbers, I wonder if only one species is causing the genus to show up. Take Oncideres for example, which is showing up with 6 observations under Chrysomeloidea. It has 1 species with 6 observations, O. germarii. Trying this same process for that species doesn’t make the genus disappear though.

Unfortunately, it doesn’t look like trying this with parent taxa fixes their children either. I tried for the family and a tribe and nothing changed.

If anyone more familiar with beetle genera wanted to make a list of affected taxa, curators could go through and edit them to make them go away.

Simply saving the unedited taxon seems to have the same effect, no need to go back and undo/toggle back.

I had tried this and it didn’t work, but maybe I didn’t wait long enough.

I tried on another of the ants showing in vespoidea searches, it took a few hours to change I think. An ok solution for taxon changes with a few descendants. But if that recent big change is the cause then is it really a practical solution to go through the hundreds(?) of changed descendants?

I’m operating under the assumption that this affects only a very small amount of descendants, in which case it’s not too much work to manually refresh the individual problem taxa. But if it’s affecting a significant number, that might not be practical and it would probably merit a broader investigation into the bug.

Try the same search in any state or country…I suspect a bug but was giving it some time to see if it resolved itself

Hm yeah that’s way too big of an issue to address one taxon at a time. Would be worth making a broader bug report now that we know a taxon split is one cause. Maybe the system needs a little more time to sort things out but I doubt it.