It would be useful for code written to access the iNat places via the API endpoints to be able to narrow the options when an encompassing place is known. For example, if you simply search for the keyword
q=victoria using the
/v1/places/autocomplete endpoint, 145 results are returned, only 10 of which are shown, and the top result of which (whether or not you use
order_by=area) is unlikely to be what someone in Canada expected.
q=victoria+british+columbia will fail, but a separate query of
q=british+columbia will succeed. So putting both together in a compound query like
victoria in british columbia (which my proposed bot code that would use the call would parse as two separate queries, the one after the
in filtering the one before the
in), then the user would be able to get the correct result without knowing in advance the exact keywords in the name that would otherwise precisely match the place for them.
And yes, without too much head-scratching, in this case a reasonably clueful user could enter search terms
victoria bc ca or even just
victoria bc and get the desired result as the top match, but depending on the place names involved, it can take considerably more effort to find the exact matching terms vs. filtering on a known enclosing place.
Therefore, I propose that the
/v1/places/autocomplete endpoint support an optional
place_id parameter that can be a place number or list of place numbers, one of which must be present in
ancestor_place_ids for a record to match.