For some time now, iNaturalist has included the following text in an alert box on the place creation page:
New places are one of the biggest sources of slowdowns on iNat, so please consider not making a new place…
For what it’s worth, we will have to restrict the conditions under which people can add places in the future given iNat’s current rate of growth.
iNaturalist is still growing rapidly and place creation remains one of the biggest sources of slowdowns, so today we added some new restrictions to place creation.
No user can create more than three new places in a 24 hour period.
The polygon drawing tool has been removed, meaning that new places can now only be created from a KML polygon upload.
Why these changes?
The place creation limit was implemented because until now users could make dozens of places very quickly, which slows down iNaturalist for everyone. We’re hoping the quota will diminish these kinds of performance impacts.
We removed the polygon drawing tool to make it harder to create places, for exactly the same performance reasons. People make a lot of places that are essentially rectangles, or crude polygon boundaries of places that already exist, and we think that’s partly because the drawing interface we had made it hard to draw complex places and easy to draw simple ones. Requiring KML files will hopefully convince people jonesing to make yet another Texas that it’s not worth the effort. For everyone else, Google Earth and QGIS are both free software packages that can be used to author KML documents.
We hope to eventually reduce the need for place creation with a better search interface (polygon tools, etc) but for now these restrictions should reduce the impact of place creation while still allowing the community to make them when necessary.
That means most of places can’t be created at all, there’re no KMLs for tons of things, including towns, why make such restriction? 3 places a day is a lot why not lessen that and leave drawing tool?
I agree. I’d rather have a restriction to 3 places / month than getting rid of the drawing tool (or keep it at least for existing places). For me, these two measures are drastically different in their effect.
political boundaries will often exist in an electronic format somewhere. in https://forum.inaturalist.org/t/creating-a-place-for-your-us-city-using-census-bureau-geography-data/21927, i describe how to get boundaries for US cities from Census Bureau data, if the city administrators don’t provide that data on their own. boundaries may also exist in electronic format in the OpenStreetMaps database or in Wikidata. worst case, you can draw boundaries yourself. there are some rough instructions for how to do this in QGIS in a follow-up post in the Census Bureau place thread referenced above. (it probably wouldn’t be too hard to create a tutorial for how to get boundaries from OSM, if there’s enough demand for that workflow.)
this restriction has already existed for many years now and continues to exist.
Wouldn’t it be possible to keep the drawing tool but limit it to very small places? It doesn’t really make sense to use it for large places anyway but it is very useful if someone wants to create a place for a local park or a garden/yard, for example for projects like those: https://www.inaturalist.org/projects/home-projects-umbrella.
Often doesn’t mean always, I couldn’t find it even for mine pretty big town, they’re not online, only maps with boundaries or cadastre maps that can’t be uploaded, so why would anyone need to draw them on different sources and not on iNat? What’s the point of it if it just complicates the life of those who create places for good, why exactly you need 3 places a day and not e.g. 1 a week? Isn’t it pretty obvious that it will slow down place creating without interrupting with it, why kill the practice whatsoever?
Why not delete useless places that are called wrong and were created automatically?
That’s the town I drew: https://www.inaturalist.org/places/korolyov, and that’s what iNat had and still has for it: https://www.inaturalist.org/places/korolev Shouldn’t it be a bigger problem than drawing tool?
Places created in Ontario, Canada, are undoubtedly contributing to the problem. For example, there are three conflicting versions of the “District of Thunder Bay,” which covers 104,000 square kilometres in Northwestern Ontario:
Only the third one has the correct boundaries. The second one is just a huge rectangle more or less centred on the city of Thunder Bay. The first one is (I think) the default…but it has convoluted - and incorrect - lines wandering across and around the islands in Lake Superior. The result is, observations from Mission Island Marsh - one of Thunder Bay’s most important natural areas - are not captured by a search for the standard place Thunder Bay - which doesn’t include Mission Island - but only by the community-curated Thunder Bay Judicial District - which does. I suspect these sorts of gaps in the mapping are contributing to the creation of community-curated places that wouldn’t need to exist if standard places were better defined.
Ontario’s Territorial Division Act and associated regulation specify that boundaries continue from any geographic township over water to the limits of the province. So, this affects any county or district fronting on the Great Lakes (and Hudson Bay in the case of Kenora). There’s no need for fiddly, inaccurate drawing around islands. Incidentally, Ontario electoral districts follow the same rules.
iNat admin could lighten the load on the servers by consolidating these conflicting upper tier places into one standard territorial division in the system.
That has been explained by the iNat staff: the specific problem here is not the existence of too many places, but the creation of new ones, particularly the subsequent indexing of all observations within the area. That’s what causes so much burden for the servers
Creating a new place means both checking to see which observations occur in it, but also it means writing the new place id to every observation inside the place. So creating a new place is a burden, but so is changing the boundaries of an existing place, and also removing a place, because all those processes require updating the list of place_ids.
Incorrect places are a problem whether you keep them or whether you delete them: keeping them means continuing to check for new obs in them, but deleting them means removing the place_id from all the existing observations, so a small continuous burden, or a larger one-time burden.
i think think the removal of the web place editor is actually intended to prevent the creation of these very roughly drawn places. it was really hard to use that tool to draw a place with very complex boundaries. so you ended up with people using the tool to draw places with very simplified boundaries. i think you’re saying that the Korolev place with very rough boundaries was “created automatically”, but it is actually community created, and i would bet that it was probably created by someone using the web place editor.
that said, i don’t think anyone is necessarily against cleaning up those roughly drawn places, and i don’t think removing a key source of these roughly drawn places goes against that goal.
There are no KMLs for tons of things → for political boundaries, you’ll find a lot of them on https://gadm.org/ as Shapefiles or kmz; you can use e.g. QGIS or R package “raster” to convert them to kml. For areas for which no boundaries are available, you’ll have to draw them yourself anyway. It might be more complicated when an additional program is required, but the circumstance that people consider whether creating the area is worth the extra effort might just be what is intended. Nevertheless, I agree on that 3 areas per day is a lot and they could have put on tighter restriction in this regards, instead.
But this one doesn’t say it was created by a user, unlike other places?
Yes, so it’s a complication of it, you as user need to find out how to do that while you already had the tool to do it, and between the two you can just give up and don’t create anything at all even if you actually need it.
i think this can happen if the person who originally created the place deletes their account (or something similar). this place has no administrative level, which means that it’s not one of iNaturalist’s standard places.
generally, the administrative regions defined in GADM are already loaded into iNaturalist as standard places, though it’s possible the boundaries or names have been tweaked slightly from what’s in GADM. so it should be unlikely that you would go to GADM as a source to load a new place into iNaturalist, unless you’re doing a lot of additional manipulation of the GADM polygons.
are you describing a process in which there’s effectively a cross-reference table that contains records with observation id and place id? that’s not technically what actually happens is it? i’ve never really looked into it myself, but i always thought that spatial indexes would eliminate the need for that kind of thing. i know that part of what the spatial index does is to facilitate the search for intersections of different features, but i didn’t think that was achieved via that kind of cross-referencing…
The requirement to use Google Earth / Q will absolutely put people off, so it’ll accomplish the immediate purpose.
My personal journey… oh bother, I had been planning to make a Place polygon for the local botanical gardens to make it easier to check through every now and then for cultivated observations. On the plus side, now I have learnt:
I assume there’s also ways to limit the necessary “caching” of locations for observations too. For instance, it doesn’t need to be checking constantly if it’s located within one or a number of location boundaries, which understandable pressures the server in a short time when you consider the number of observations and locations on the site. Personal locations shouldn’t have equal priority to formal locations like county, state, and such.
