There are two different things going on with the “obscuring” issue.
One is actual obscuring on the map, which I don’t think many people have much of an issue with.
The other is removing them from the list of species from an area, which is a big problem as the presence/absence of species helps to direct conservation management.
A system by which the map location and the specific coordinates on the observation are obscured, but where the species is still listed for the observation area would satisfy both the supposed poaching/rare species location issues as well as retain the conservation benefits that iNat was intended to provide.
I think the concern here has been that someone really intent on locating an obscured observation could create (and delete again) a series of increasingly localized places to see which ones did and didn’t contain the obscured taxon, until it was narrowed down enough to go hunting.
Would someone go to that trouble in practice? Mostly not, but probably depends on the value of the organism. And as iNaturalist grows, so do the chances…
Since the other topic was about how the obscuration/unobscuration process should work, this different subject seems more suited to its own topic. Feel free to change the title.
They can do that anyway by going to the Explore view, zooming the map in, redoing a basic search in the zoomed view, which establishes an AOI. The observations that are obscured in the list of a project in the same area show up in the list generated by the AOI view.
The rationale that it’s a protective measure falls apart given that you can do that.
Given that my work is in protecting rare species and that poaching is a large part of my work (I run three anti-poaching teams in my area) it’s more than a little frustrating to have a valuable conservation tool that we can use to help combat poaching in the area turned into something that no-longer assists in that effort.
i have issue with things being obscured on the map when they shouldn’t be, such as common tree spaces that happen to be at the edge of their range. I personally care about that about as much as I care about the ‘areas’. But maybe i’m weird in that way.
i think it’s never going to be totally secure, if nothing else hackers could get in, after all much much more ‘secure’ sites than iNat such as financial institutions and government military servers get hacked. iNat is never going to be a place to store super top secret data and people need to use common sense. It used to be that was the policy, and while auto obscuring also does make sense in some cases, if it goes too far it will do a lot more harm to conservation than good.
I agree with earthknight that removing obscured species from an area is not helpful. Example: Town projects. If a town is trying to document biodiversity and obscured species are not linked to the town project, then significant observations remain unknown. This isn’t helpful. Maybe the project administrator who is familiar with the area should be the one deciding whether or not the observation can or cannot be linked.
@earthknight@charlie just to clarify, I agree with both of you that minimizing the effects of obscuration is highly desirable, consistent with net positives to conservation. Was just suggesting how the issue with lists might have originated in the past. Seems like it might be an unintended leftover of past practice that was changed in other contexts – but just speculating there.
There is no point to obscure something on a map and then show it on a list. You may as well just advocate that the obscuring be turned off, which may get some traction, but I suspect not.
Allowing self appointed project admins to decide they get to see locations of at risk species because they are familiar with the area is wrong. I made those observations available knowing their locations would be obscured or made available only to people I have explicitly granted permission to.
If as a user you still feel you must have access to this data then use and old style project which has been set up with this in need and accept that there is work required and some users may still choose not to share.
Please leave the new Collection projects as they are.
The last thing iNat needs is to be known as a location where gaining access to locations of sensitive species is easy.
That depends on the size of the place. In the case of a large place, like most national parks, excluding something doesn’t make sense. if it’s a tiny community garden, it does. The issue really is that the random-point-within-square model is problematic because then you can infer where the observation is located if the obscuration rectangle barely overlaps the boundary of the place at all. But that’s a function of how iNat obscures not something that makes it impossible to include observations in a place. I think there are probably creative ways to improve on that, but no easy solutions.
seems like we need a broader conversation of what and how to obscure. I personally have become worried about this issue because current and proposed actions really reduce the ability to see things that don’t have any credible risk. When something is truly a collection risk, like a rhino or a super rare orchid or something, it’s important to be extra careful.
I think we should consider tiers of obscuring, perhaps. Also, consider finding a way to base obscuring based on risk rather than rarity, which is a little harder but would be a lot more effective.
imho the last thing iNat needs is to stop being a useful conservation tool. That concerns me more than poaching risk really, though i think we still need to carefully consider that. The biggest cause of ecosystem-level collapse which drives most extinction is habitat loss and associated issues (invasive species, fragmentation climate issues associated with fragmentation, etc), not poaching. Poaching only harms a few high profile species and while that’s certainly important, if we trade poaching for habitat loss we still lose those species, and a lot more too. Most species being driven to extinction by poaching have already been severely been impacted by habitat loss.
That depends on the size of the place. In the case of a large place, like most national parks, excluding something doesn’t make sense. if it’s a tiny community garden, it does. The issue really is that the random-point-within-square model is problematic because then you can infer where the observation is located if the obscuration rectangle barely overlaps the boundary of the place at all. But that’s a function of how iNat obscures not something that makes it impossible to include observations in a place. I think there are probably creative ways to improve on that, but no easy solutions.
The size of the place isn’t actually relevant. As soon as there is a way to automatically determine some subset of the obscuration box that a particular observation falls in, you can find the exact location of any observation to any degree of precision with a bit of work (binary search). I think it would be easy enough to write a script to do it automatically. Unless there is a way to distinguish the project “Great Smoky Mountains National Park” from the project “Great Smoky Mountains National Park except it’s shifted 100 metres to the east”, this is unavoidable.
The alternative is requiring manual approval of all project places before they will display obscured observations - but this is a huge workload. And just thinking about it, I’m pretty sure I could still game that system in many cases without anyone noticing.
I think we should consider tiers of obscuring, perhaps.
Yes, this seems like a potentially good idea eventually. There are already two tiers (obscured vs. private), but in many cases the current obscuring is far too much (e.g. the bioblitz landowner issue that you’ve brought up before Charlie, or some personal home locations, where even if things were only obscured to within a couple of kilometres that would likely be plenty).
Ultimately obscuring is never going to be entirely compatible with other parts of the inaturalist project. The solution is to obscure as few things as necessary.
I don’t understand what you are saying here. If you are in the middle of Yosemite and obscure something there, the park boundary goes way beyond the obscuring boundary. If there is some other loophole i am not understanding it (and you probably shouldn’t describe it here in detail since it’s a public forum).
I don’t think it will ever be perfect, no matter what. There’s always some potential problem with it. We just have to do the most good and least harm, and finding that balance will be tricky.
I don’t understand what you are saying here. If you are in the middle of Yosemite and obscure something there, the park boundary goes way beyond the obscuring boundary.
Don’t such observations where the box is fully contained already show up in projects?
oh, i thought you were including those in your comment, but i probably just misread. Yes if something has an obscuring box that only clips the edge of Yosemite, the same issue exists. Same with obscuring a fish at the beach when the majority of the box is on land, other things like that.
This issue here is how do you distinguish the “Yosemite National Park” project from the “boundary I’ve specifically created to reveal locations” project. I think this is an insurmountable problem without manual approval of projects, and still a very challenging problem even with manual approval.
yeah i see what you are saying about that, and yeah, creation of user projects probably shouldn’t ever show rare species, unfortunately (i had originally wanted to create places for small wetlands I survey, that is one reason i did not). I think the only real solution is having standard and nonstandard places and the standard ones would act differently. While that represents more work, it also has other benefits. For instance, anything in a large area of southern California I observed came up as ‘Rachel’s Area’ in the location description… and not only did Rachel not own most of the San Bernardino Mountains, Rachel didn’t use iNat any more. Those sorts of things should be tracked and displayed differently. (though to be fair if it were created today Rachel could just do a collection project type setup)
Yes, that first option is fine. It’s not a great solution (as you’ll now be including some observations that weren’t within the project limits, and some observations from within the project limits will not be included), but I see no reason (except perhaps technical ones) you couldn’t have the option on collection projects:
Include obscured observations if the obscuring box falls entirely within the project boundary (current default)
vs.
Include obscured observations if the obscuring box falls partially within the project boundary
I don’t think the default behavior should be changed though.
that’s a good option… because for most conservation uses you’d want to know about rare species adjacent to your area of interest anyway. Especially animals since if it’s in that area it may roam through even if it wasn’t there at the time. And for focused surveys and bioblitzes you just discourage people from roaming outside the boundary.
This is not how it works now as I understand it. How it works now is a certain percentage (which dev team has chosen not to disclose) has to be outside the geographic boundaries of the geography for it to be excluded. if the percentage of the bounding box that is within the geography exceeds that number, then the observation will be included in the project, and on the map.
This is a search for records in a project dedicated to a large provincial park in Ontario(as seen in the url parameter) for an obscured species in the province of Ontario. 2 of the 3 records from this user have portions of their bounding box that fall outside the park boundaries, yet they are still there. in fact the ‘fake’ coordinates for one is outside the park, yet the records are still there.