Hi Tony - I have a hopefully related comment for you as I represent a volunteer entomologist group that uses iNat data frequently. I'm the admin for
https://www.inaturalist.org/projects/moths-of-ontario
https://www.inaturalist.org/projects/ontario-butterfly-atlas
and we use iNat data in provincial atlases for each group (links to the atlases are on the project page if you are interested). Both atlases are curated data aggregation projects, and vetted iNat data is standardized and combined with other observations from individuals as well as GBIF, eButterfly, BAMONA, museums etc.
As an organization, we encourage users to consider iNat as one of the options for sharing data, and in the case of moths, it is currently our single largest data source. One of the reasons that we like using iNat is that is reasonably easy to use for observers, and for us when we download data. However, there are friction points that, if you could eliminate them, would make life easier for observers and data consumers.
There are several issues that I see from an observer’s perspective, and I posted a response on Carrie’s thread.
For us, the mechanics of getting data out of iNat and getting it suitably scrubbed/formatted is bit time consuming (it’s a volunteer group with no real IT specialists).
Our projects are focused on lepidoptera and life stage information is vital for us. But there are multiple ways that observers can supply that info, through the annotations and a staggering variety of duplicative fields. I and others have asked to have annotations available in downloads as far back as last summer, and despite Ken-ichi putting it on the to-do list, we still can’t access that simple data (see his note on July 25 on this thread: https://groups.google.com/forum/#!topicsearchin/inaturalist/annotat;context-place=forum/inaturalist/inaturalist/V06_UTD1cTU).
I also wonder if you can’t populate the life stage annotation with the computer vision output. It clearly recognizes larva for many common lepidoptera, so if the suggested ID is Monarch (adult), Monarch (caterpillar) or Monarch (pupa), that may improve data quality for everyone. As an aside, I am very impressed with the results of the suggested IDs across life stages.
Another issue with data output is suboptimal location descriptions that we receive. The input box on the web has a search box and, effectively, an output box. What is curious is how disjointed those two can be. See the attached example where I entered a popular camping area in a major park, both of which are google locations, however, the resulting iNat location description is bordering on useless. We prefer specific location descriptions, so when we run into these examples, we either discard them, or look up the location for significant observations. Neither of which represent good outcomes. Why can’t the observer’s search term be the default location description? This is also linked to the concept of saved locations that I mentioned on the other thread. I believe that saved locations would not only simply observer entry, but would lead to better quality output in terms of accurate location descriptions.
We prefer to have the real names of observers, so the proliferation of vague handles is a nuisance and we message people with significant observations to ask for their names. I wonder why you can’t adopt an ebird style default where people provide their real names.
The download options are also puzzling. When I am downloading from a project, I do not understand why any fields other than those used in that project are presented as options. Conversely, some fields that are added by users to observations in the project, but not used by me, are not available to download.
Good luck with the retreat. I know that these are not particularly flashy upgrades, but addressing them would make your site so much better for groups interested in using detailed data.
David