really? even if they are sort of meaningless without context?
i guess if you really love statistics, below are the user / observed date (local time) combinations that have the highest observation count, based on an old copy of the AWS Open Data Set (from 2021-04-15).
the main limitation of this approach is that this would include only observations that had licensed photos as of that snapshot. so for example, if you compare the count of the first row in the table below vs https://www.inaturalist.org/observations?on=2018-06-05&place_id=any&subview=map&user_id=biobank-lantauhk&verifiable=any, you’ll see that there’s a 500 obs discrepancy probably due to a number of casual (no photo) observations. so the approach is not perfect, but it’s more efficient probably than trying to go through the API.
| User ID | User Login | Obs Date | Obs Count |
|---|---|---|---|
| 547666 | biobank-lantauhk | 2018-06-05 | 3217 |
| 547666 | biobank-lantauhk | 2017-07-26 | 2740 |
| 20600 | danielatha | 2020-10-31 | 2155 |
| 25160 | michaelbakkerpaiva | 2018-06-29 | 1854 |
| 420537 | astrobirder | 2019-08-06 | 1665 |
| 20600 | danielatha | 2020-07-29 | 1543 |
| 420537 | astrobirder | 2020-01-05 | 1390 |
| 264009 | ck2az | 2019-06-19 | 1352 |
| 420537 | astrobirder | 2019-06-07 | 1346 |
| 20600 | danielatha | 2020-03-15 | 1339 |
(it may be interesting to note that none of the dates above seem to be from the CNCs.)
it someone wants to get stats using more recent data, they can get the observations metadata file form the latest AWS Open Data Set snapshot, index it on user_id and observed_on, and then run a query like this:
SELECT observer_id, observed_on, COUNT(*) as obs_count
FROM observations
GROUP BY observer_id, observed_on
ORDER BY COUNT(*) DESC
LIMIT 10