This
https://www.inaturalist.org/observations?list_id=4399234&photos=true&place_id=21&subview=map
returns results for the full species Habroscelimorpha dorsalis rather than only the subspecies Habroscelimorpha dorsalis media that is on this list
https://www.inaturalist.org/lists/4399234-temp_zero_EOs_20230330?view=plain
and I don’t understand why. Sorry if I am missing something obvious.
1 Like
You did not select a taxon, and you did not set the “HIGH - LOW” to “SUBSPECIES - LOW” in the filters;
This is the link that should only display observations of Habroscelimorpha dorsalis media within that list
https://www.inaturalist.org/observations?hrank=subspecies&list_id=4399234&photos=true&place_id=21&subview=map&taxon_id=509935
2 Likes
Thank you very much, as I was unaware of that and it will be helpful in the future, but I don’t think that solves my issue if I’m understanding correctly. I was trying to get observations of all, and only, the taxa on the list I’d created.
@bouteloua Thank you for putting this in “bug reports”. I would have, but wanted to make sure it was a bug and not something that I was misunderstanding or doing incorrectly.
i didn’t check the code to see what it’s actually doing, but i would suspect that if you’re filtering by a list, you’ll get back “leaf taxa” (which go down only as low as species).
back in the day when the system was populating lists, you would have gotten species and all their ancestor taxa included in a list, and if you filtered by a list, you probably wouldn’t want to filter by those ancestor taxa. so instead the system probably uses leaf taxa, and as a consequence, leaf taxa will go only as granular as species.
in other words, i don’t think this is a bug. i think this is what the system was designed to do.
I don’t know if I understand what you’re saying, but the url is filtering on a list_id, one taxon on the list is a subspecies, and the results I’m getting include the full species and other subspecies neither of which are on the list. If this is how it’s supposed to work, it makes no sense to me. Related, would it do the same for a traditional project based on a list? And thank you
are you familiar with the concept of a “leaf taxon” in the system?
1 Like
I guess I misunderstood, my apologies!
I read about it, and it may make sense within other contexts/situations in iNat, but it still makes no sense to me that if I am filtering in part to a particular subspecies using a list that I get results for other subspecies.
1 Like
leaves go down only to the species level, not to subspecies.
if the filter works like i think it does, it filters leaves, meaning it goes only as low as species.
This is the crux of the issue. Whether it be a bug report or feature request, I think it’s unexpected behavior that the search results would be showing any higher taxon than, or sister taxon to, what is included on the list.
2 Likes
if you had a list that consisted of a particular animal species and all its ancestor taxa, what would you expect to happen if you filtered for that list id? should it get observations only for that species? or should it get observations for all animals?
This isn’t a list of all ancestor taxa of the subspecies (i.e. only a subspecies is displayed on the list), but sure in your hypothetical where all ancestors are displayed on the list page, I’d expect to see observations at rank Animalia and taxa IDed at ranks in between the specific species and below.
that’s interesting. if i’m interpreting your comment correctly, you’d expect to see a filter on list return a result set like exact_taxon_id=[taxa on list with descendants] OR taxon_Id=[taxa on list without descendants]
because old life lists are created the way i was describing (with all ancestors), i was thinking that filtering on such a list would only be useful if it returned taxon_id=[leaf taxa in the list]. (otherwise, it would just return anything in the kingdoms observed.)
it turns out neither of these expectations is actually the way the filter works.
…
so i actually did a little testing, and it turns that if you filter by list, you’ll actually effectively get taxon_id=[taxa in the list].
and when i go an look at the observation-level results in the link in the original post, i do see only results for H. d. media among Habroscelimorpha dorsalis observations returned. so as far as i can tell, the Explore screen is actually returning the observations that the user expects, but either the original report needs to be clarified or the user expectation of how the Explore page works needs to be clarified because this isn’t really true:
when i go to https://www.inaturalist.org/observations?list_id=4399234&photos=true&place_id=21&view=species&iconic_taxa=Insecta, i see that the species H. dorsalis has 23 observations:
this is correct. all 23 observations of H. dorsalis returned in the result set are H. d. media.
now, if i click on the ‘23 observations’ link (https://www.inaturalist.org/observations?list_id=4399234&photos=true&place_id=21&view=&iconic_taxa=Insecta&taxon_id=120976&page=), that will take me to a page that returns 177 observations and includes other subspecies. i would characterize that behavior as a limitation of the the way the Explore screen works. it displays leaves down to species level on its species tab. so any links associated with these will be only as granular as species. that’s just the way the screen works for better or worse, unlikely a bug.
alternatively, if you filter for both the list and a taxon to narrow down the results (ex. filter by your list and by H. dorsalis species – https://www.inaturalist.org/observations?list_id=4399234&photos=true&place_id=21&taxon_id=120976&view=species), you might expect that this would return only the 23 subspecies observations, but it returns the 177 species observations. this is probably because the list_id parameter is being effectively translated to the taxon_id parameter. so if you are effectively filtering by taxon_id=species,subspecies, you’ll get back everything in the higher taxon.
…
all this is to say that although my original suspicion of how the filter works was incorrect, the original report is also not quite correct, and at the end of the day, it still seems like there are no bugs here.
you could make a feature request that the leaf links on the Explore screen should somehow direct you only to the subtaxa present in the original result set, but i bet that’s more complexity than it’s worth to try to implement.
Thank you. That is very interesting and I did not realize it. I see what you mean as far as how it works and that it may not technically be a “bug”, but that is not the behavior a user would expect and it is not useful. Also, clicking a link that says 23 observations and getting 178 seems just plain wrong. The list plus taxon id does work if I manually tweak it to the ssp instead of the full sp id. https://www.inaturalist.org/observations?list_id=4399234&page=&photos=true&place_id=21&subview=table&view=&taxon_id=509935
Thanks again for figuring out what’s going on.
i suppose the bug report can be closed?
That’s up to iNat. To me, it’s still an unfixed “bug” as there’s no way that it should work this way; especially the “click on a link to 23 observations of one taxon and getting 178 for multiple taxa” part
1 Like
the way this is phrased is still a little misleading, especially since the quotes imply that that’s what someone else actually said above. what i actually wrote was:
1 Like
I wasn’t quoting you; I was giving a name to part of the issue, like the “facebook defaulting to top comments” thing, and meaning that that part of the issue is especially wrong and sorry if that came across as a misquote of you.