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 (Android, iOS, Website): Website
App version number, if a mobile app issue (shown under Settings or About):
Browser, if a website issue (Firefox, Chrome, etc) : Firefox, Chrome
URLs (aka web addresses) of any relevant observations or pages: Identify
Screenshots of what you are seeing (instructions for taking a screenshot on computers and mobile devices: https://www.take-a-screenshot.org/):
Description of problem (please provide a set of steps we can use to replicate the issue, and make as many as you need.):
i don’t think there’s a bug here. i think the way those filter parameters are designed to work is that “without annotation (value)” must function in conjunction with “with annotation (type)”.
logically, it wouldn’t make sense to filter both “without evidence of presence” AND “without evidence of presence=track”.
conceptually, i think folks would want something like “without evidence of presence” OR “without evidence of presence=track”, but filtering in the system generally doesn’t support OR, unless it’s defined within a specific parameter on its own. in other words, there’s not a specific parameter that handles the combination of (“without evidence of presence” OR “without evidence of presence=track”), though i guess you could make a feature request for that sort of thing.
I am trying to see all observations that are not annotated as tracks. I don’t want to specify anything “with annotation (type)” since most new observations don’t set any annotations. Ideally I would indeed like to be able to specify multiple without annotations (NOT tracks and NOT scat). The Without Annotation filter is not equivalent to With Annotation NOT track. It filters out all annotations “Evidence of Presence: Track”, but lets through anything without any annotation. BTW: The bug report is NOT abouth whether the filter works, it is about the fact that the filter looses the Track setting and reverts to “Without annotation: Evidence of Presence: Any”.
i get what you’re trying to accomplish, but as i noted above, i don’t think the system is designed to accomplish this:
…
i’m fairly certain this is by design. it looks to me like it’s the system’s way of telling you that:
…
within the current design of the system, i think the closest you can get to your desired result is to select “With Evidence of Presence” and “Without Tracks”, though this will only give you observations with an evidence of presence annotation.
then to get the rest, you can filter for “Without Evidence of Presence.” it would be a 2-step process.
to get the system to do it all in 1 step, i think you need to start with a feature request.
I think you are wrong in your assessment. It is designed to do exactly what I am looking for, it just doesn’t do it right. I just tried it again. It does exactly what I want, but then it forgets the setting. It is not a problem that it doesn’t do what I want, the problem is that it forgets what it is doing.
I checked some more. It actually works all the way. It does remember the setting even though it doesn’t show it. It does get applied to subsequent pages even without showing it in the filter. The bug report is really only about the display of the filter not its working.
Now I need to make a feature request to have multiple “Without” settings.
if you know how to do this somehow, please share the steps that you’re taking to accomplish it.
i’m trying to filter for my own raccoon observations (https://www.inaturalist.org/observations/identify?reviewed=any&quality_grade=needs_id%2Cresearch&taxon_id=41663&user_id=pisum) that have either no evidence presence annotation OR evidence of presence = something other than track, and i don’t see it happening. i can get observations without evidence of presence, and i can get observations with evidence of presence = to something other than track, but i can’t get both at the same time. (2 of 10 these observations have evidence of presence = track.)
@pisum, What you are trying to do can’t be done with the current system. You can tell the filter to let through a specific Evidence of Presence (or any) OR to filter out a specific Evidence of Presence (or any), but not both. It does an AND between the two filters, you want to do an OR, which it can’t do.
i’m sorry. i must be misunderstanding something here. when you say “It actually works all the way” and “It does get applied to subsequent pages”, what exactly is “it”?
It is the filter that I try to put on the observations to ID. I don’t want observations of tracks. When I set the filter to not select observations with Annotations: Eveidence of Presence: Track, update the search, go to the next page with observations, and then look at the filter again, it doesn’t show the Track anymore. But it still filters out observations marked as Track.
i’m sorry. that’s still not clear in the context of what’s been said so far.
can you provide a screen a screenshot of the filters menu? and also the resulting set when you apply your filters against my raccoon set of observations?
based on what you were describing, and since 2 of 10 of my raccoon observations have a track annotation, i was thinking you were saying you could somehow return 8 of 10 of those observations.
but you agreed that it’s not possible to return 8 of the 10 of the observations.
so then which of those observations are your filters returning?
EDIT:
i think it’s filtering out observations marked as track because it’s filtering out observations with any evidence of presence annotation, which is why you should see something like this in your filter menu (on the next page):
You are right, it doesn’t work. The filter ignores the Track setting and reverts to Without Annotation: Evidence of Presence: Any. When I apply the filter to your data set, it returns the 4 observations that don’t have any Evidence of Presence, instead of the 8 that don’t have Track.
Here is a screenshot of the filter setting.
ok. i think we’re beginning to get some agreement here. let me know which of the following you agree with at this point:
if you set “without evidence of presence” and “without track”, the system is dropping the “without track” and filtering using only “without evidence of presence”. so this effectively results in observations with no evidence of presence annotation.
you would input:
but the filters would actually resolve to this (on subsequent viewings of the menu):
if you set “with evidence of presence” and “without track”, the system will get observations that have an evidence of presence annotation other than track.
you would input:
but the filters would actually resolve to this (on subsequent viewings of the menu):
you cannot filter for all observations without track annotation because you cannot filter for 1&2 at the same time.
the system is not currently designed to filter for 1&2 at the same time. (there is no bug in the context of the existing design.)
or maybe if there is a bug, it would be that the screen allows you to input “track” after input inputting “without evidence of presence”?
filtering for 1&2 at the same time will require writing up a feature request.
According to my understanding you are not quite correct. The filter that you have as 1. should work, but doesn’t. I think this is a bug. It should not change Track to Any, it should select observations that do not have Evidence of Presence: Track, 8 observations in your case.
so is it fair to say that you agree that points 1-3 above represent the current state of affairs in terms of how the system is actually behaving? but you disagree on points 4 and 5 because you believe the behavior in #1 is not working as intended?
I will agree with @geichhorn that there is a bug here, but I’m not sure if it is in the filter design or just in the user interface - I have no way of knowing what the intent of the designers was. If, as @pisum suggests, it was the intent of the designers that the “without annotation” field should not be used without first selecting the “with annotation” field, then that should be communicated to the user. In the filter menu, there is no indication that those two options are linked, so as a user I would assume, as @geichhorn has, that they operate independently.
Thanks to @pisum for laying the cases out so clearly!
yes, i can see both sides. i think the implementation tried to simplify the required UI layout and filter parameters, but that design leads to the quirks/limitations we’re discussing here.
i think a more robust implementation would represent this functionality using 3 main UI input options, with the first option having a couple of optional choices associated with it:
with annotation type (can function on its own or with one of the options below):
a. annotation value
b. not annotation value
without annotation type
without annotation value
… and this is how they would map to parameters:
case
API parameters
SQL parameters
1
&term_id=[type]
term_id=[type]
1+a
&term_id=[type]&term_value_id=[value]
term_id=[type] and term_value_id=[value]
1+b
&term_id=[type]¬_term_value_id*=[value]
term_id=[type] and term_value_id<>[value]
2
&without_term_id=[type]
(term_id<>[type] or term_id is null)
3
&without_term_value_id=[value]
(term_value_id<>[value] or term_value_id is null)
* note: not_term_value_id would be a new parameter
1, 1+a, and 1+b would be mutually exclusive, but 1 [+a/b], 2, and 3 would be allowed to be used in conjunction with each other.
for an even more robust implementation, you could add special handling for 2 to find only nulls/unspecified… and for an even more robust implementation, you could add handling for mulitple type/value inputs… (slippery slopes!)
