Hi, yes with 47 I meant the target species. We didn’t do any filtering before, only in sorting out in excel. The reason we had all bombus species included was because of our overall targets of the organized bioblitz. We exported the data several times, and each time something was missing (this varied which of the observations were missing). As mentioned before, we couldn’t identify any logical reason for this.
Thus, I cannot really say why now all the observations are included. Good if it’s working now!
this thread probably should be merged with https://forum.inaturalist.org/t/export-counts-do-not-match-up-with-stats-count/9515 at this point. that other thread has a better description of the underlying issue, plus a link to a Github issue that describes a possible resolution.
1 Like
I’ve moved the github issue to a high priority in our Web project.
Platform -Website
Browser -Chrome
relevant url: project: https://www.inaturalist.org/projects/bc-checklist-obs
I attempted to download all the observations in a particular project. (I recently created this project; it contains a series of 2791 casual observations that were uploaded as a series of batch csv files; they are all very similar and contain records from a publication). When I’m setting things up in the “download” page, I see 2788 observations in the preview. I’m pretty sure the 3 that don’t get there have taxonomic issues - I’m not too worried about those 3 missing. However, many others are up issing from the download, and that is my concern. When I execute the download, despite 2788 showing up in preview, I only get 2767 observations, and the missing ones are not random; they’re almost exactly every 101st record in the sequence of observation numbers, corresponding to the order they were uploaded in the first place. The download is missing obs nos. 101, 202, 303, 404, 505, (NOT 606; it’s there for some reason!), 707, 808, 909, etc. The “missing” observations exist in iNat, but don’t get into the download. This seems to be some kind of artifact of the download process, or perhaps of the upload process? I can see no causal differences in the actual observation fields, between those included and excluded in the download. What gives?
Step 1: navitgate to https://www.inaturalist.org/projects/bc-checklist-obs
Step 2: go to the filter, and click “download” to extract records to a csv file
Step 3: check the preview, then do the download and look at the data.
the downloaded data does look a bit strange, but i think it’s worth noting that your data looks sketchy to begin with. it looks like you’ve created a bunch of casual observations in the system in an attempt to replicate some sort of published species checklist. i’ve created junk observations occasionally just to test some functionality, but this seems a bit excessive.
for what it’s worth, the technical issue seems to be a variation of the problem described at https://forum.inaturalist.org/t/export-counts-do-not-match-up-with-stats-count/9515. what’s similar in that case, this case, and another case in the past is that the only export criterion was project id.
2 Likes
Thanks for responding, @pisum , I do appreciate it. Perhaps what I’m doing is excessive (see below); but it raises an issue about the reliability of an iNat query/download. If it’s only my sketchy data, that’s one thing, but what if it’s all sorts of other queries? Difficult to know, without an understanding of what the underlying problem is. I see that the related problem you link to was never resolved. Does this happen every time someone queries a project instead of a more lengthy set of parameters? Does anyone have any solutions to this, or at least theories about what’s going on?
For the record, that set of observations is a list of all Lepidoptera records from a thoroughly vetted published list. Not exactly junk, but not “proper” iNat observations either. Note they’re all “casual” so they’ll never contaminate research-grade data. Perhaps I’m “gaming the system”, but what I’m exploring is whether iNat might be used to generate a definitive list of all the moths and butterflies known from British Columbia. A simple query of BC iNat records is missing the hundreds of obscure tiny moth species that may never accumulate iNat observations, but which we know occur in BC, based on taxonomic publications. That’s what the set of casual observations fills in. The published list is out of date, and most of the new records are coming from iNat. Hence I am experimenting at creating a hybrid - that set of casual observations for the established literature records, plus newer “proper” iNat observations including new discoveries. And if iNat’s taxonomy is kept up to date (it’s pretty good thanks to all the curators), then a nice bonus is that this iNat hybrid list would always be taxonomically current. But it’s all moot if iNat can’t reliably deliver a set of queried records. That is a problem to more people than just moth enthusiasts in BC. Anyway, thanks for your thoughts.
there actually is a “place checklist” for British Columbia in the system: https://www.inaturalist.org/check_lists/7425-British-Columbia-Check-List. i think lists are being phased out of the system, but this used to be the feature that would allow you to add species that had been recorded from other sources, in addition to what had been observed in the system.
I haven’t heard this. There is a proposal to revise how place-based checklists work (see iNat’s blog post on Upcoming Changes to Lists), but the basic functionality of having an observation-independent checklist for a place will (I think) remain. (The last comment – by @loarie in April 2022 – on that post says they are still waiting for the engineering capacity to implement the proposed changes, so probably no change soon.)
3 Likes
i guess what i was getting at is the “auto-listing” feature of place checklists will be separated from the manual inputs at some point. so, as i understand it, instead of having the “hybrid” list that the original poster was trying to create, you’ll have a dynamic list based on observations only and separate list(s) based only on manual inputs (or legacy data). in other words, using the place checklist might have been the way to combine observed species from the system and other species reference data, but that may not be true for long.
1 Like
this thread probably should be merged with https://forum.inaturalist.org/t/export-counts-do-not-match-up-with-stats-count/9515 at this point. that other thread has a better description of the underlying issue, plus a link to a Github issue that describes a possible resolution.
This should be fixed now.
3 Likes
This topic was automatically closed after 18 hours. New replies are no longer allowed.