I have asked Admin about this previously but the problem persists. When I search for items in Toronto (Ontario) the boundary given by iNaturalist is so badly drawn that the search misses out on much of Tommy Thompson Park, a 5km long peninsular jutting into Lake Ontario. I have not searched anywhere else for similar issues but I suspect that if boundaries are drawn as badly for anywhere else, people who are trying to submit records with any accuracy will find their records likewise omitted from any searches. I have had to move several of my Park sightings to locations several hundred metres out of place just so that the point can be included in any search. This rather flies in the face of attempts to post accurate data! The fix would simply require a more careful re-drawing of boundaries that donât cut out large chunks of terra firma, but I think that is something that only Admin can do (happy to take this on if non-Admin dudes such as I are actually able to fiddle with the boundaries!).
See this post: https://forum.inaturalist.org/t/wonky-county-borders/4433
If the issue is just for searching, you can search for the community uploaded place instead. Or you can upload your own.
The simple polygon used for Southeast Texas excludes a large area of land along the border with Louisiana and the gulf coast. The East Texas polygon follows the state border and coastline, but includes many habitats and species not found in SE TX, so is pretty useless if you are only familiar with the SE TX habitats that are more similar to the rest of the American Southeast than they are to most of what is covered by the East Texas polygon. I do sometimes use the place American Southeast, but there are a lot of species differences (mostly the same genera) in plant communities on the opposite side of the Mississippi River and even more in peninsular Florida. It extends a bit too far west also IMHO, but not nearly as much as East Texas does. You canât make new large places anymore. So you have to make a project with several places to fill in the gaps.
This happens for a lot of European subdivisions too â the London boroughs are often shifted and distorted. Hereâs Kingston, where the border is meant to follow the Thames until just west of Surbiton, (a few hundred metres out) and where the south is meant to follow the margins between that field and woodland around Malden Rushett (the tip is ~1km out!)
For some places (especially where their borders are defined by natural features, or it results in them half including a park) it can really distort the checklist. Kingston has had the fairly uncommon alien Impatiens capensis (orange balsam) recorded, but iNatâs checklist doesnât show it - because itâs on the Thames which the outline doesnât include. Likewise, where it dips down into the rural areas near Epsom (Epsom and Ashtead Commons, very precious nature reserves!) it picks up species it shouldnât.
@paul_prior I think you imply that the problem with observations missing from a search has to do with an improperly created polygon. Tracking down who originally created and uploaded the polygon for any given place is quite difficult on iNat. It might have been staff; it might have been imported from some third party database (and thus not editable); or it might have been defined by some iNat user, the source of which is anyoneâs guess. âAdminââwhoever that might be on staffâcanât address all these eventualities.
You didnât specifically mention this but the most common issue involving observations left out of âplacesâ is the observation accuracy. Do your observations have a small enough circle of accuracy that the entirety of that circle is in the place polygon? As you are probably already aware, if any part of the circle of accuracy of an observation falls out the defined polygon, the observation will not be included in any search/collection/project.
Similarly, the place called âOregon and Washingtonâ omits a chunk of eastern/southern Oregon and the tip of the Olympic peninsula, but includes a chunk of Canada. Drives me nuts.
A similar problem is evident for the whole China. The roads as mapped are offset by several 100 m relative to the satellite imagery.
For example, see: https://www.inaturalist.org/observations?place_id=6903&subview=map&verifiable=any
The mapped roads and satellite imagery match perfectly on the Russian side of the border, but are offset on the Chinese side.
It is more accurate to map observations in China using the satellite imagery, rather than via the mapped road lines. It is very confusing!
Since thereâs no way to tell which sytem the observer used, a lot of obervations near the border may be posted to the wrong country.
In your case, you can just use the two states with a comma in between. Like this:
the China GCJ-02 vs WGS84 issue is a completely different problem that has to do with Chinese laws and regs rather than the place boundaries defined in iNaturalist.
on the website (but not in the apps) you also have the option to use OpenStreetMap tiles, which folow WGS84 and will line up with Googleâs aerial imagery.
So related to examples like the Toronto (Ontario), East Texas, and the Oregon-Washington polygons above, I have a question for staff:
@tiwane Does staff have knowledge of the owner/originator of such custom and erroneous polygons? Based on some type of metadata associated with a polygon, can staff tell/distinguish if it was imported from some third-party (e.g. web-origin), an iNat user, or some other source?
Anyone can view that in the lower left of a placeâs âaboutâ page. If it was created by someone on iNaturalist, their username and the date created will be there. Many were created by people who havenât logged into the site for years.
Thanks. That answers part of my question to staff. However, non-user-created places lack any source information, such as,
https://www.inaturalist.org/places/toronto
https://www.inaturalist.org/places/greater-austin
So my questions remains: How can we determine the source and/or editability of such places? How can places created by inactive users be edited?
from my perspective, the only meaningful distinction between places in the system is âstandardâ vs. âcommunity curatedâ places. if thereâs an admin_level code on the place, then itâs a standard place; otherwise, itâs a community curated place.
you can find that code via the API. (given the Greater Austin place you linked to above, the easiest way to view the underlying information for that is to add â.jsonâ to the end of the link and navigate to that â https://www.inaturalist.org/places/greater-austin.json â in your browser.)
the standard human interfaces offer only less direct ways to get that information. for example, you could use the Places of Interest feature in the web Explore pageâs map view to sort of get that, or you could find an observation that falls within the place and look for find an observation that falls within the place, and look at details > encompassing places for that observation.
Ankara map is also incorrect. It covers some of the Kırıkkale province. TĂŒrkiye.
I have similar issue with the city I live in Poland (my topic https://forum.inaturalist.org/t/incorrect-border-for-cities-in-silesia-poland/64908 ) and it turns out, that what we need is update of automatically created places with newer GADM maps which are far better than te one used currently on iNat.
Good God! I hope people arenât adjusting the locations of their observations just to conform to place boundaries defined on iNaturalist. To my mind, the cure is far far worse than the disease.
Noting that if the user who created the Place deleted their account, the Place has no âownerâ, their username is no longer associated with the Place. I suspet thatâs what happened with https://www.inaturalist.org/places/greater-austin
(sorry, I started capitalizing âPlaceâ in our help docs to try and signify that it means a particular thing on iNat, so I do it all the time now.)
Yes, thatâs what I do to double-check its status.
Agreed. But making a change like that would likely necessitate downtime of several days, itâs not a simple fix. Every observation would have to be reindexed.
same with Zanzibar. If you explore âZanzibarâ iN suggests Zanzibar, Tanzania. You get only Zanzibar West. To get the whole of Zanzibar you have to know what to ask, put in Zanzibar Archipelago.
I agree, Rick, which is why I am trying to bring to the attention of Admin, searching for a solution. Unfortunately, though, yes, I have moved points 100+m to ensure capture within the TTP site boundary, still within the Park but not as accurate as Iâd like.
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.