Ben Armstrong

Here's another case, but it's not quite the same as the cases above. If you search for `rhododendrons`, the matched_term is `rhododendronsläktet` which very likely is not what you'd like...

Without any fancy weighting strategy: - We can use `taxon_id=48460` to prune entries without valid ancestry as our starting point and per_page=0 initially to get a count of candidate taxa....

Oops, a small problem with this is that # of results is not the same as highest id# allocated. So I propose: - default a global config max_taxon_id to 1260000...

One slight refinement is there's no need to do random number selection more than once. just pick a number between 1 and the maximum (as per previous comment) and then...

I'm not entirely happy with this plan. I'd rather see a standard OAuth webapp flow here. But that would involve writing (and hosting somewhere on the web) a whole webapp...

If I'm going to go ahead with #161 and use the bot to update projects, I might as well keep this one on the books and tackle it after that...

I have now added a comment to the forum post linked above, requesting that page previewing be improved in their HTML. I also asked for an index of the taxonomy...

Alternatively, `,obs anthophila from pa with native`. There is no separate `means` parameter in the observations search API: https://api.inaturalist.org/v1/docs/#!/Observations/get_observations It just has `native=true`, `native=false`, `introduced=true`, `introduced=false`. If we stick closely...

Re. my last point, I posted to the iNat forums here to get some input: https://forum.inaturalist.org/t/autocomplete-severely-constrained-by-api-limits/31298

Note re "bot detects a profile link". Users often do not provide a link, but simply mention their profile in some other way. It's hard to cover all the cases....