I think I already know the answer to this but want to make sure I’m not missing something. We have a traditional project that users join and trust so we can get access to true coordinates. We download observations periodically and enter worthy ones into our database. It would be great if there was some way to exclude a long list of observation IDs, that we’ve already downloaded that we’ve been using to winnow out already-downloaded ones, but I can’t think of a way to do that.
why wouldn’t you want to download everything, in case the observations change over time?
Once positively IDed observations are in our database, we do not have any reason to look for updates and it wouldn’t be feasible anyway as the data are transformed before upload, plus there are a lot of observations. Also, many of the ones we want to exclude turned out to be incorrectly IDed or not identifiable from the images.
if you download and then review everything all in one shot in a way that you would never want to download any of those observations again, then the easiest way to exclude would be to filter by id_above
or created_d1
. the idea here is that you would exclude anything with an obs ID or submit date greater than the latest record from the last set downloaded.
if you can’t do it this way, then because:
you wouldn’t be able to just exclude using not_id
(unless you did something complicated in conjunction with id_above
and id_below
). so then you would have to use some other mechanism to identify things you want to exclude, but there’s no perfect solution here. so pick your poison:
reviewed=false
requires that you have a specific user as the reviewer- observation fields and inclusion in traditional projects can’t be applied to all observations
- tags can be applied only to your own observations, and i don’t think there’s an easy way to perform exclusion on tags
- faves are not easily filterable and probably would require a specific user
- it’s possible to filter for observations with identifications for a particular user or
pcid
(includes a project curator id), but i don’t think there’s an exclusion version of these filters
Thank you but none of those are near-palatable poisons. The ID/created is creative but would exclude observations that didn’t meet our criteria at the time of last download. The reviewer=false wouldn’t work for this but was not on my radar and will be useful for other sleuthings and so thanks for that. What would be ideal would be to be able to batch add/change a custom observation field or similar.
that’s an option, but as i noted, not everyone allows others to add fields to their observations.
We could ask project members to give us permission as they do for geoprivacy but that would only work if there’s a batch way to add/populate the field, which I don’t think is possible.
i believe this is an all or nothing thing. either they allow anyone to add fields, or no one.
it’s possible via API. if you’re not comfortable with that, you can use @megachile’s browser extension to add fields.