Description of need: When identifying observations that have been stuck at family, I see both observations with only family identifications, and observations with disagreeing identifications at lower levels. I want to be able to choose to only see the latter.
Feature request details: To be able to exclude the observations that have identifications of a certain taxon.
The functionality would be a new URL parameter: without_direct_ident_taxon_id= which would have the same effect as without_direct_taxon_id= but instead of checking the community ID, it checks the identifications, like ident_taxon_id= does.
Yes, because the identifications are disagreeing, so the community ID would be the next common taxon up. without_direct_taxon_id= excludes observations of a taxon where the community ID is lower than the level of the taxon, and without_ident_direct_taxon_id= would also exclude observations at the level of the taxon that have at least one identification for that taxon. Is that a helpful explanation?
i’m a little confused. i asked whether my filter should return the observation, and you said:
your explanation was:
but if we apply this logic to my example case, my observation does have at lease one identification for the taxon horse. so according to your stated logic, my observation should be excluded. so if i query for without_direct_ident_taxon_id=horse, i should not get my observation, right?
Currently, there is no parameter to exclude identifications of the taxon within observations with the community ID as the taxon, which is what is searched above. I think this might be the only use case of this parameter.
but look at the column labeled “ID Count @ Obs”. based on the value there, you’ll know whether the record has a Tabanidae ID.
if you’re referring to your proposed parameter, yes, it’s possible as long as someone wants to implement it. it probably would not be the most performant filter, since it would effectively need to do something like a NOT EXISTS, but it’s not terrible in terms of these kinds of parameters.
i could, but i’m not going to change this page, since every workflow is different, and different things are important to different people, and i can’t possibly handle every potential workflow. just for example, i mentioned earlier that cases where ID Taxa @ Desc(endant) > 1 (even where ID Count @ Obs > 0) could be a sign that there’s not a branch disagreement here. so for me, i would tend to open up those observations, too, to see what’s going on.
(you could also adapt my page or else code your own thing to do the additional filtering in a more automated way. even just extracting the results of my page into Excel so that you can sort records based on the various ID statistics might be enough to help you handle the manual filtering a little more efficiently.)
this may be true, but i kind of feel like when you try to find the last few percent of cases that might be interesting, you often end up jumping through hoops anyway. for example, even if your proposed parameter was implemented, you still wouldn’t be able to automatically filter for that case that i mentioned just above, where there is an improving Tabanidae ID that is not a branch disagreement. but scanning through the ID statistics on my page, you’ll be able to find those cases relatively quickly.