Despite the definite need for improvements, like how places on maps stay orange when they should turn green, I enjoy the places feature of iNat. Sometimes, when deciding which state parks to visit, I’ll take a look at their checklist to get an idea of what to look for while there, and sometimes I even factor in whether I’m likely to find many new species to add to my life list while considering which parks to visit.
However, I am very aware of the burden this feature has on iNat’s servers. Because of that, I’ve been very careful about creating them, and to my recollection, I’ve only created one or two, I know one of them is for example a riverside park on 110 acres of land with ~500 observations.
But what would you consider to be the boundary between a place which has a net positive effect, helping to track the species present in a specific location, and those with a net negative effect, which burden the server without providing a practical purpose? Do places this small have a negligible effect on servers, or not?
I think if a user is going to regularly make use of a place (make a project, track species there, work with others, use it as motivation to observe more) and it meets the iNat guidelines above, they should feel free to create it.
Sometimes it’s frustrating not to be able to add more than 3 new places per day (I wish I could define several UTM grid zones at once, now that I am trying to add more records to the database https://flora-on.pt - each such place is defined by just 4 points, so it shouldn’t be much of a burden) but I’m fine with that restriction if it is necessary to prevent spam and abuse.
Perhaps a user should be prompted to justify the creation of a new place and perhaps provide the URL for a detailed description of that place, in the same way that a user must provide some references to justify changes in the taxonomy…
The number of points used to define a place does affect “cost”, but also the size of the place and the number of observations it contains, with larger places having higher cost. So even a “simple” place that is large would place a burden on the system.
Specifically for UTMs, I think that it would be a large burden if many UTM grids were added to iNat. I also have a hard time seeing why UTM grids are particularly useful as iNat places specifically. For formal analysis or use with databases, I imagine that any points could be IDed by/assigned to UTM zone after download quite easily.
In regards to
for smaller places, I don’t think this is necessary myself. For one thing, there isn’t really a process whereby places are evaluated by curators or staff and acted upon. A place doesn’t change anything (like an ID) that other users depend on. Additionally, for many places, there might not be an online source for their boundaries, either because they are from part of the world where online sources for places don’t exist in many cases or because they are informal/user-defined solely (yard projects, parts of school grounds, etc.)
the more often the place is actually used, the more justification for its existence. if you’re not going to use it, and nobody else is likely to use it either, or if you’re only going to use it once or twice, it probably doesn’t need to exist in the system.
to the extent that you can use the Explore page instead of a checklist, creating a place without a checklist should reduce the burden on the system.
you can get this information without needing a place.
I use iNat extensively for mapping plant species that are either rare on their own (e.g. Potentilla montana) or indicative of rare habitats (e.g. Arenaria montana). Much of that information is then uploaded to the platform https://flora-on.pt which is maintained by the Portuguese Botanical Society and is the reference about plant distribuitions in Portugal. That database is organized by UTM grid zones. The assessment of the conservation status of a particular species takes into account the number of UTM grid cells where that species was detected (among several other parameters, of course). Therefore, it is relevant to
“swipe” UTM grid cells in search for endangered species.
That’s where iNaturalist comes about. In my (voluntary) field work I use the iNaturalist app all the time to check where I am, where I’ve been, where I saw that species before, where I am most likely to find it - in a particular UTM grid cell that I am exploring that day. For this purpose, I use the “explore” feature and search for observations in given place, that place being the UTM grid cell whose boundary has been previously defined and uploaded. By doing that, not only do I see the boundaries on the map but I also see what has already been observed in that cell.
Does this represent an excessive and unjustifiable burden on iNat servers? I don’t know. But this seems legitimate to me, it dramatically increases the efficiency of my field work, so I’ve been doing it.
In the comment immediately before yours I described what I have been doing.
Defining boxes is trivial in the website, but that functionality does not exist in the mobile app (to my knowledge). I do all this mapping voluntarily with the resources available, which means using the cell phone rather than a tablet, for example. In the small screen of a cell phone it is not practical to open iNaturalist in the browser, so I only use the app during my field work - and the app only allows me to search for observations in a specific UTM grid cell if I previously defined that cell as a “place”. That’s the issue.
If the “explore” feature in the app is updated in order to allow the definition of SW and NE corners as can be done in the browser, then the definition of UTM grid cells becomes almost irrelevant, because the boundaries of those cells are approximately (though not exatly) along meridians and parallels.
How regularly is “regularly”? If the place is a specific school grounds created for a class project, does conducting the project every school year make the place a net positive?
Perhaps we would be able to make better decisions about creating or not creating new places if we understood better the computational burden that they represent.
When does a new place require the most computational time? The computational burden is high only when the new place is created, because the system needs to check all records in search for those which belong to that place? The computational burden is high every day / every hour / … because that assignment of observations to places is updated periodically? The computational burden is still high each time a new observation is uploaded or a new search is performed? If so, how high is it compared with the computational burden of the CV algorithm (which I expect to be immensely higher), the upload of the images, etc.? To what extent does the computational burden depend on the number of points of the place’s boundary? To what extent does it depend on the number of observations in that place?
We need to understand this better in order to weigh the pros and the cons of creating a new place - and only the programmers can elucidate us about this. @cthawley any clues?
Even if the programmers don’t disclose that information, perhaps they can estimate the burden of the places already created by a user and define a limit to that burded. Once the limit is exceeded, the user will not be allowed to create new places unless he/she deletes old places (but then, we also need to know whether the deletion process would decrease or increase the computational burden…).
By the way, so far I believe there’s no practical way to get a list of all places that I defined already: I have to remember their names and then search for each of them. Either I personally keep a record of all places that I created or at some point I might even forget some of them and lose the notion of how many they are. Making it easier to see that list might discourage the users from creating new places. Like: “Wow, I already defined 100 different places, I will refrain from defining a new one!”