i think what you’re describing is a different issue. see: https://forum.inaturalist.org/t/problem-with-the-explore-part-in-the-application/30430/5.
it’s really not a great idea to just change observation coordinates to get them into a particular boundary.
if you haven’t already, you should consider the solution referenced in @thomaseverest’s referenced link above, which is to search using the City of Toronto place rather than by the Toronto county-level place.
if the City of Toronto place is still excluding too many observations, then you could search on a combination of multiple places, such as Toronto + Tommy Thompson Park + Toronto Islands.
it may also be worth reading the link i referenced above in my response to yusufzanzibar.
i’m not sure exactly how indexing works with ElasticSearch, but i’d be surprised if there wasn’t a way to do something like this:
- as of a given date create a copy of the production database and index framework. i’ll call this the parallel environment
- reindex every observation in the parallel environment.
- take down the production environment after the work is done on the parallel environment.
- either:
a. copy the observation index(es) from parallel to production, and then reindex all observations that have update dates after the parallel copy, or
b. start with parallel and apply all database changes from production (from a log filte, or something like that) since the parallel copy, and then reindex all observations that have update dates after the parallel copy. at that point, parallel becomes production.
sometimes, i also wonder if the strange North America boundary negatively affects overall performance in the system since its bounding box effectively spans almost the entire northern hemisphere. if so, fixing that might be reason enough to go through the effort of getting new standard place boundaries.