I don’t think you should assume or they should expect you to assume that all their observations are always going to be from the same place.
+1000
And plenty of observations on iNat have very precise location information, which is completely inaccurate.
I don’t know if you’re talking about me, but I don’t think I ever “objected” to obscured observations. I simply choose to ignore them. You want to obscure your observations? No problem.
You can read some of my thoughts on the matter here.
Life is short. Save your sanity!
That was helpful* - I haven’t spent a lot of time understanding the data-handling consequences for projects and other end users, I’ve just ticked the boxes to allow project access and hoped that solved all the problems.
It is frustrating that iNat made the change to obscure the date as well. “Date privacy” concerns have limited overlap with location privacy concerns, and it should be up to me whether or not I want my data treated that way.
*I also learned what TANSTAAFL is. ;-)
In many cases, obscuration probably has limited impact on external data users, as long as the data users understand the (arguably) bizarre coordinate randomization that iNat performs on obscured observations. These users are often processing the data in bulk, and they probably don’t have to reveail details of individual observations in whatever their end product may be (say, a paper that analyses observation data for a particular species).
I’m not sure what the implications are for iNat data that ends up on GBIF. Do the “real” coordinates/dates for obscured observations end up on GBIF? If so, what prevents someone with bad intent going to get the information they want from GBIF (aside from the dreadful UI) ?
And even for the ones that do have it users often turn the off to increase battery life. I do this with my cameras.
Yeah, I manually place all my observations. I’m usually aiming for “in the circle, as best as possible.” Sometimes this means a really big circle bc I don’t remember exactly where I was, and/or it’s a trail and I can only use a circle bc that’s what iNat supports (i.e. polygon feature requests have been turned down due to website issues).
I have asked many times, and it mostly gets ignored. People either do not read and adhere to suggestions, or dump the obs and leave.
I would clear those obs from my URL. Select all their NID or Unknown obs - Mark as Reviewed. Next. Observer and identifier need to be a team working together.
Or not. Some other identifier is welcome to a turn.
I don’t have GPS and I work hard to place my obs as best I can on satellite view.
Real/true coordinates are not on GBIF. The Obscured locations/coords are on GBIF, and the accuracy/precision (can’t remember the name of the field on GBIF) is given as the diagonal of the 0.2x0.2 box as on iNat. So it is clear that the location is imprecise. The true date **is **on GBIF (and I think in iNat downloads as well?). Not showing the date on iNat’s display pages is not a strong protection, just a feature to make it harder for the date to be used to figure out observation details.
That’s perfect. So the folks who simultaneously argue in favour of hiding the dates for obscured observations on iNat, and for having their obscured observations reviewed and otherwise treated the same as other observations are shooting themselves in the foot. Anybody who really wants to figure out where they were on a particular day just has to follow the breadcrumbs (unless they are diligent about obscuring all their observations for the date in question).
It would work a bit better if people obscured all their (nearby) observations for the date they made their observation which they are trying to hide. Some people do this, but I suspect that many fail to think it through.
I’m not sure which interfaces it’s “hidden” in, but I see it any time I place a location, and any time I identify an observation, regardless of what device I’m using. Here it is on iNat Classic:
On iNat Next:
On the website:
On the Identify tab:
It seems like it should be impossible to not see it, unless you bulk upload a bunch of photos to the web and don’t ever even click the automated location for each one to make sure it’s right. But in that case, the whole location could be entirely off and you’d never know it.
Thanks for following up. I should write this up as a feature request (if it hasn’t been done already). The basic problem is that the GPS accuracy value does not appear on the main screen of the web uploader. As mentioned, you have to click on the location to bring up the edit screen but I suspect many users never get to that level. In my case, I would rather not bring up the edit screen if I don’t have to (and in most cases I don’t since the location data is embedded in the image file) but in any case, if the GPS accuracy is faulty (which is common with iPhone for example), the user should be able to see that on the main screen of the uploader. In the case it is missing altogether, the user should be made aware of that, in the same way an alert is displayed if one or more observations do not have an initial ID. All of this is true of the mobile app as well.
If a user is pestered a little bit on the upload screen but does not fix the problem, that same user will not be able to complain too much if an identifier also asks for resolution. The user interface should be setting boundaries on user behavior. If you leave that to the identifier, there are bound to be problems.
PS. I realize there are multiple platforms where GPS accuracy is unattainable (or only attainable with extra work). In all cases I can think of, the uploader is the proper time and place to address the issue, even if it’s merely a matter of pointing the user to the appropriate help page. Once the observations are uploaded, it is too late I’m afraid.
You’re not wrong. But based on my own experience, I think you’re going to have observers who simply cannot be bothered to enter/edit an uncertainty value. I get observation data from a number of sources, including spreadsheets submitted directly by the observer. Even though the template I provide to these observers contains a column for lat/long uncertainty, some very active observers who have been submitting observation data for decades simply leave it blank. Others get confused over what the lat/long uncertainty is intended to convey, and enter inappropriate values (even though I created a YouTube video illustrating exactly how to fill in the spreadsheet).
I’m one of those who upload observations through the website uploader, not through an app. My camera (an Olympus Tough) gives me lat/long, but not an accuracy value. When I’ve checked the camera’s location against obvious features in an aerial photo, it’s usually accurate within 8-10 meters, which is good enough for me. Since I usually upload thousands of photos every year (over 11,000 last year), I do not want to add an accuracy value manually to every observation, particularly when I cannot be sure what that value actually is for each observation. So, I’m afraid anyone who requires an accuracy value to use my observations, they are out of luck (or they can message me and I’ll tell them to use a 30-meter value). Sorry about that!
This is why I don’t require an uncertainty value on the lat/long - but it would be nice to have a meaningful one. It can be difficult to come up with a strategy to manage data from multiple sources, where many observers have idiosyncratic ways of reporting their observations. iNat enforces a certain degree of consistency in terms of format, but folks hammer square pegs into round holes all the time. When you try to point out that the thing they’re trying to force into the wrong place doesn’t belong there, they just reach for a bigger hammer.
I just wanted to add my 2 cents. I do this for a lot of birds in Indonesia to confuse the bird catchers. Even in the usa, I once shared a location for black rails. Since then, gangs of birders are there every year terrorizing the birds (trampling marsh vegetation to flush and corner rails). The obscured locations are too close if you know the habitat….
I use a phone app to create a track file while I’m observing and then geotag the photos with that afterwards. When I upload the observations I just “select all” and only edit the accuracy field in the location box (I usually do 15m if I was hiking, higher if I was a passenger on a highway or something).