When creating a new place on iNaturalist you have to go to google maps, google earth or an other map to create a kml file and then upload it onto the “create a new place” and add the name for the place, then add the parent place, then add a place type.
There can be a few problems with doing this -
You can’t add a big area
It is “biggest sources of slowdowns on iNat” as mentioned there on the Warnings
I think it would be easier if it is possible, to add where it says “Include Places” two options - search for a place and manually add a place (similar to using lines when creating a polygon in google maps)
I approved this so that there’s a public reponse from staff, and have sent it to close in about a day.
This is definitely functionality we’ve discussed quite a bit and would like to do it, so I don’t think it needs to be voted on. It’s something that would take design work, new functionality, and probably a new way to save boundaries that aren’t places, so adding it would be a pretty heavy lift.
Creating a place means you have to upload a kml file from a online map like google maps, onto “Create a new place” on iNaturalist.
Basically, this place can be used by everyone and is an area you can search up in “places”. Creating a boundary on a project means you just use it for the project not as a place you can look up in “places”, just an area for one project.
kml files take up a bit of data, so creating a boundary on the project would save a lot of data.
That project boundary would still have to be stored by iNaturalist in a form that can be used for spatial queries to collect observations for the project. So I’m guessing it would end up being stored within iNat in the same format as Place boundaries already are, and there would still be the same load on the system to index observations falling within that project boundary. Unless I’m missing something, the only differences would be that no one else can use the same boundary, the boundary can be any size (which still creates a proportional load on the system if used to index observations for a project), and there wouldn’t be any option for an associated place checklist.
I think the main advantage is that observations wouldn’t be indexed as being in one of these boundaries, which I believe is how places as they current exist cause the most burden on the infrastructure. Right now for each place we keep a list of which observations are in each place and it’s cosntantly being updated as observations are added or removed from that place. I think what’s being asked is more of a way to draw a polygon and have it behave the same way the rectangle and circle searches work in Explore. Then when you load the project page, iNat just performs a search dynamically for observations in that polygon the way it does for rectangles and circles now, instead of reindexing observations in the background.
The size of KML files isn’t an issue, the largest ones we allow to be added are 1 mb for non-curators and 5 mb for curators. Its a places effect on observation reindexing that’s the issue.
Thanks for clarifying Tony. Seems like dynamic spatial searches could still be a big system load, depending on boundary size and how frequently the project page is accessed or refreshed. But maybe it’s still a good trade-off vs. indexing.
I think the project searches would be no different than any other search someone might do in an area (Place or custom boundary). These no doubt happen often and much more so than someone accessing a project.
Something could be implemented and called a “Private Place” or “Project Only Place” that doesn’t come up in regular searches but can be selected from the project editor.
There used to be a Place Editor but it was removed a few years ago, presumably to reduce the number of unnecessary places being created. This could perhaps be reactivated for creating a hidden place as it was quite nifty.