I’m trying to collate observations for various regions in California, to learn organisms by ecoregion, and compare what I have observed to what is common in that habitat. I am using WWF ecoregion: California interior chaparral and woodlands, but the KML file is too large: 1.1 MB (rounded to 5 decimal place precision).
I can’t reduce the precision further because that would be less precise than the location accuracy on iNaturalist, but the file as it is is only a little bit over the limit - the reason is the complex boundary.
Thank you.
Could someone add the ‘Bahamian-Antillean mangroves’ then please? It also has a complicated boundary and it might have less than 200,000 observations as the area is small and only a bit in the US.
In general, I think that the 1 mb limit is present for a reason (places are a large drain on iNat infrastructure) and that it’s not great practice to make case by case exceptions in response to solicitations on the forum.
Yeah, the limits are there to prevent places from consuming too much of iNaturalist’s resources and slowing down the site. I’d recommend trying to make the boundary more simple, if that suits your needs, or splitting it into multiple boundaries.
I don’t think I can make it more simple. Essentially, I want the boundary to mesh with the other ecoregions, and I want the place to be useful to others in the future, so I can’t simplify it more than would suit these needs, as well as maintain accuracy at least equal to the general location accuracy of observations on iNat.
For instance, I already have the other two habitats in Jamaica, and I don’t want to keep having to update this place whenever I need something more precise. Also, if people were to come to rely on the place I made (because they are interested in the ecoregion and it is the only delineation of it available), there would potentially be a bunch of observations that never get seen by them, if I simplify it too much.
OTOH a lot of the features of places, which seem to slow them down, are probably not needed, since searching an area with a drawn-in boundary in the explore page is possible and fast. So I was requesting a separate feature to save all these boundaries with high fidelity so they can be used on the map search and also for projects (to compare biodiversity in places that are matched for habitat, for example).
I have a feature request I wantto post about this, but I posted one on Saturday/Sunday, along with a bunch of drafts, and they were all turned down, and it was requested I wait before resubmitting one.
(I also don’t know how to simplify kml files… I can only import and export things from google maps. I don’t know how to work the boundary drawing tools inside google maps - if it works the way I think it does, this boundary would either be ridiculously simplified, or too tedious to draw.)
For sure, and this is something we’ve talked about a lot. Probably won’t happen until the Explore page is rewritten, though. So I don’t think it needs a feature request on the forum, it’s on our minds.
I showed all the places I would like the ‘place’ to be usable, including the filter taxon pages, the include/exclude filters on projects, the ‘location’ dropdown in Explore, and for an Explore page limited to the region to be available after clicking on the region.
I also made an argument for maintaining boundaries for at least one set of ecoregions on iNat (which would be cheap then), and probably a couple of the more well-known and well-documents, and managing them through updates like with the taxon framework. It would also be possible for users to upload their own, less-well-known sets.
I read those, but those discussions were done under the assumption that places are expensive for iNat. After Explore is fixed and places are offered in the various search bars which are cheap, that no longer applies as a reason not to ‘burden’ iNat.
A poster in one of the previous threads, for example, mentioned ‘not knowing which ecoregion a given user wants’, where each user might have a different ecoregion set in mind, and so it doesn’t ‘make sense’ to implement all of them (provided, of course, they’re expensive).
I simply suggest importing ALL of the well-known, ‘official’ ones, and letting users add the rest. Once places of this sort are simply stored files w/ the boundary data (which I’ve seen staff admit aren’t large, it’s the indexing and re-indexing which is the drain), there is no reason to be forced to choose one, so not knowing which of the 3~4 mentioned someone will want is not a compelling argument to not have 1~2 of them, or all 3~4. I think place-revamp changes the ecoregion discussion.
Plus, I’m all for them for the reasons the OP in that thread is - they make better sense than the political boundaries, or at least as much sense - people think in terms of their country so iNat supports this, but iNat, being an organism-focused site, should consider that organisms themselves belong to habitats and habitats to regions and these cross political boundaries, so I think it should provide ways to search in this manner as well as by political boundary.