New Limits to Place Creation

a hopefully relevant question, is it possible to download the kml of a place that is already on iNat?


the thread describes other ways to get this data, along with limitations of the approaches.


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.


If big places are the problem is it not better to prevent making huge areas ? I do not understand why one should make custom huge areas.


it may be worth noting that folks who use Google Earth for place creation may still need to work around the issue described in it should be harder to create a place in QGIS that will trigger the same issue.

political boundaries will often exist in an electronic format somewhere. in, 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:


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:, and that’s what iNat had and still has for it: 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

1 Like

That’s not quite the whole story.
Every observation “knows” which places contain it.

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.


boundaries for Korolyov do exist in OpenStreetmaps: so you could get those boundaries in KML format via the Overpass API. see using either of the scripts noted in that post and replacing the relation ID to the ID for Korolyov (184109), i was able to export a KML file that i was able to load into QGIS:

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 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…

1 Like

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:

  1. how to draw a polygon in GE:
  2. how to export a polygon kml from GE:

I have to admit the GE drawing tool is a lot nicer than the one just withdrawn here.


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.

I just checked on two place-related things I used to complain about and wanted to say thanks for fixing them. First was the duplicated continent-sized places in different languages (ie. North America and Norte America). Second is that the sorting has been fixed so now when you search for a place like Nevada, the state (or country or continent) is at the top of the list instead of buried in a long list of smaller places.


Is there a naming convention? That will improve searching for it (Country-Province-Name-Type). I think other websites are much more strict in adding and naming areas (,64215.0.html)

I found a nameing convention

Zonder plaatsnaam krijg je niets zeggende aanduidingen als: de Zandput, Willempolder, Voorstraat etc.

Bij kleine dorpen is een nadere indeling van de bebouwde kom niet nodig, bij grote dorpen en steden is dit wel vaak wenselijk. Ook parken e,d, binnen de bebouwde kom mogen ook een eigen naam krijgen.

Gebruik buiten de bebouwde kom namen van polders (eventueel opgedeeld in deelgebieden), bestaande veldnamen, gehuchten, straten. Gebruik voor "en omgeving" e.o. Maar altijd voorafgegaan door de naam van een grotere plaats.

Het is mogelijk gebieden nauwkeurig in te tekenen. Het meest ideaal overlappen de grenzen niet, maar in de praktijd is dit lastig. Laat de grenzen dan iets overlappen. Het kleinste gebied wordt altijd gekozen als locatie-aanduiding.

Geef wateren (meren, plassen, vennen) een logische naam, maar ook wat grotere kanalen, watergangen, rivieren kunnen worden opgedeeld in deelgebieden.

Kanaal door Walcheren - Veere-Middelburg
Amsterdam-Rijnkanaal t.h.v. Utrecht

Rijkswegen mogen ook worden ingedeeld: stukken van maximaal een kilometer of 10, met toevoeging van de naam van één nabijgelegen plaats. T.h.v. is overbodig, liever ook niet "tussen Erp en Kwerp", dus:

A58 - Arnemuiden

Knoopunten als volgt aanduiden:

A12 / A35 - Knooppunt De Hop (Geldermalsen)
A6 / A81 - Knooppunt Haarlem

Rijkswegen begrenzen t/m de bermsloot.  Knooppunten beginnen bij de uitvoegstroken van de afritten, inclusief alle lussen en bijbehorende bosjes e.d.

Het is handig op een kaart bij de houden welke gebieden je hebt aangemaakt. Het is ook handig eerst te kijken welke gebieden er al bestaan in het gebied dat je gaat opschonen! Vaak is dit te zien bij "werkgebied"  op de site van een locale werkgroep, of door met de muis op de kaart te klikken alsof je gaat invoeren, óf door een link aan te vragen waarbij je via Google Earth per provincie alle ingedeelde gebieden kunt zien (en bijv. ook gebieden die nu nog vierhoeken zijn).

Houd bij de begrenzing van gebieden rekening met de grenzen van de gemeente; bij voorkeur geen (gemeente)grensoverschrijdende gebieden.

De gehanteerde gemeentegrenzen zijn niet erg nauwkeurig en zijn exclusief de watergebieden. Op verzoek kunnen deze worden aangepast. In beginsel moeten ze eigenljk allemaal worden nagelopen, maar dat is nogal een klusje...
Nu nog mooier :) (kun je zelfs je eigen kaartlagen toevoegen)

I would suggest being very careful with trusting GADM. I have yet to find a place with accurate boundaries on GADM for my country (South Korea). This issue has been a problem since I joined iNaturalist and as I’ve brought up in the past is a frequent frustration.