the way i read some of the arguments against the changes is that folks don’t want the obvious weaknesses in the obscuration to be mitigated because those weaknesses allow them to get to the true locations. in other words, they still want access to those back doors.
i think the approach outlined by staff is fine. if you’re going to provide a method to obscure the location, then it should obscure the locations as much as possible technically, and access will be controlled via standard workflows / processes (ex. providing project curators access to private coordinates). close the back doors as much as you can, have people go through the front door, and allow the observer to decide whether to open the front door or not.
Personally I would like to see it kept simple: either a taxon is high-risk and has taxon geoprivacy applied, or a taxon is not high-risk and does not have taxon geoprivacy applied. I don’t think we need a gray area there. Not even sure what that would look like.
Several times, when I have had a research interest in a taxon whose taxon geoprivacy seemed unnecessary, I have flagged the taxon for curation, started a discussion, and in most cases reached consensus to remove the taxon geoprivacy. I don’t think that is too much to ask when someone has more than just a casual research interest in a taxon.
Depending on how often that user gets out, perhaps. The original rationale was to make it more difficult to deduce locations by looking at other observations on the same date; but if this is a user who only has the opportunity to get out into nature one day or weekend a month, even showing the month could be a giveaway. On the other hand, for highly mobile species, if it has been more than a few days, they may not even be there anymore anyway. So for more frequent users, obscuring the date would have more benefit to the species than for occasional users.
That seems to be the conclusion I would reach, too.
Doing some IDs this evening, I realized that I do find that display of the number of observations is quite useful as a gauge of how to respond to a given user. Number of observations often tells me how experienced a user is with iNat and allows me to modify my comments accordingly.
It might even be useful to display the number of IDs a user has done.
so i made this topic to pull out the observation count issue partly because, while it is discussed here, it’s a) not explained as to how this is an effective means of obscuring an observation and b) i think it is something to be discussed from the identifier’s workflow and not in the larger yelling about datetimes and everything else.
i don’t see that it does much but!, if it is a concern, i would be fine with a rounded number or binned to know on that ID panel if i am looking at a very new user, a moderate user, or a heavy user. and i want to know that to suss out copyright issues, for example, for those low obs count users. it is a useful number even if it’s only <50 or >5000. and i want to know it for any of the set that is affected by the obscuring policy.
I found this topic because I was curious why so many observations have obscured dates now when I’m reviewing and IDing things. I understand the reasons for the new functionality, but I did want to point out that it can add a new layer of difficulty for some IDs. Many lepidopterans and odonates have flight periods that barely include a particular month, and exact date can help a lot in narrowing an ID because of that.
For example, I periodically go through Rural Skipper IDs to check for misidentifications of the very similar Woodland Skipper. Rural Skipper records from later than the first few days of July are almost always going to be Woodland, so knowing the exact date within the month can be very helpful for finding those misidentifications.
Anyway, this is a relatively minor impediment in most cases, but there certainly must be examples of virtually identical species that can only be identified by date. The new functionality might make it almost impossible for identifiers to make a species-level ID in those cases. This isn’t a complaint; I just wanted to include the point in the discussion (sorry if I missed it being mentioned already in the thread)! :-)
Just wanted to add now it’s impossible to see if screenshot date or photo of the screen date is updated and uploaded correctly to the system, it’s just blank, should we add a comment and mark them incorrect anyway until user answers or should be leave them be as they are?
Many new suers post not original photos, but screenshots or photos of camera screen, they usually have wrong date and time, but with current system you have no ability to check if it’s true, you don’t see exif, no date of upload, etc.
Oh, I see. I don’t think that has anything to do with this topic. Either way, I assume the answer is still no, but it’s a good idea. I’d make a new feature request if I were you.
It is related to this topic (as it happened so it’s where we now discuss everything changed with new system), but anyway I just need guidelines what to do (don’t need to have dates shown, but to know if I can still mark&comment them or just don’t react, I know people marked them before even without clear evidence of wrong timings).
I think obscuring the date is, all things considered, a good idea. I’ve been doing it manually with some of my observations anyhow.
But, when I download a csv of my own observations the date is still obscured, as far as I can see. Am I doing something wrong (missing a column or something)? I think the real date should be included just like the real coordinates of my obscured observations are included
i’m not sure exactly what’s going on in these cases, but i suspect that if the user fails to input true coordinates and still makes the geoprivacy private, the dates will not get obscured. this is kind of an edge case, but the failure to obscure could still allow location interpolation even though the true coordinates were never input.
I sincerely hope that iNaturalist has a procedure by which researchers can request and receive all the data. I mean, contact iNaturalist staff, present the research project and references from relevant conservation agencies, universities, etc., and get the full data. (Asking each individual observer for it is not practical on many levels.) If there is such a “behind the scenes” method, I’m OK with whatever obscuring iNaturalist imposes, though it can sometimes be annoying.
I understand doing this for auto-obscured species, but does this have to be done for manually obscured observations? That seems a bit pointless. Also, why is a user’s number of observations hidden?
No, I understand someone obscuring something for privacy reasons. But why should the date be, too? People are usually obscuring observations at their house, right? If they’re doing that, all of the observations at their house will be obscured. You won’t be able to find one that wasn’t obscured and figure out where it is that way.
