The best way to do this is to create a traditional project or a collection project (turn on trust for the latter) and persuade observers to join and trust the project. More information on projects can be found on our Managing Projects page. The observer has to join your project and choose one of the “Yes” options for the project curators to access the hidden coordinates.
If researchers need the info I will put the observations in their project and choose the option to allow them to access the coordinates. Or sometimes I’m mailing them a sample and will fill out the lat/long in a form or on an envelope.
Another method to obtain these coordinates is to have the user trust you, which they can do via the Manage Relationships link on their Account Settings page. If they trust you, you will be able to see all of their private or obscured locations.
I have friends that know where I live and that I know will not poach things who I share all my obscured locations with using the relationships function.
As with everything, moth vagrancy is really complicated. As with birds, the likelihood of vagrancy varies dramatically among species. There are some groups whose flight habits result in them routinely moving hundreds or thousands of miles and showing up pretty much anywhere. These include some Sphingids, black witches, Spilomelinae, Eudocima, Hypocala andremona, etc. Then there are species where the males and females are differently prone to movement- if you find one single female Papaipema you could be miles from a host plant, because they move out and travel widely to lay their eggs. And there are species where vagrancy is practically unheard-of, and finding one even a mile or two away from their preferred habitat would be extremely strange- moths that only really flutter around among low foliage rather than across open spaces where wind can catch them, and even ones that are flightless. In these cases, I’d want to ask something like “did you find this on a ridge top shale barrens?” before confirming an ID, because micro habitats can be important for identification. Heck, there are some butterflies I encountered in Alaska where the easiest way to identify them was to ask what size of rocks made up the talus slope where they were found- some Erebia are really picky about these things.
So I’d say in most cases, a 20-mile radius is sufficient to make an ID of a moth. But I reject the generalizations I often hear on both sides, ie “What do you mean it isn’t found here? They’ve got wings, don’t they, and the moths don’t look at the range maps” on one side and “I need to know the location to make an ID, which means if I can’t see the exact field you caught it in I won’t even guess” on the other. Both of those assertions are warranted sometimes, but for 99% of IDs, there’s no need to go there.
Personally, this isn’t my rationale for not identifying obscured observations (for what I do, the obscuration of the date is usually more of a problem than the obscuration of location). Even if someone joins our project and gives permission for us to see their coordinates, I generally don’t ID them because I don’t want to use their data. To my mind, if I include an obscured observation in our database, I am then obliged to provide at least an equivalent level of security WRT the location/date as iNat provides. Even if I can do that for data viewed via our website, we get third parties requesting data from our database. Once we provide data to a third party, we lose all control over security of the information. I don’t want that responsibility, so I just steer clear of obscured observations.
I didn’t mean this to such a consistent extreme, but I see how you would’ve thought that as I was trying to use such an example to support why making the:
Point is inconsequential. However, my mind is usually on birds, so I was probably being too general
Now that’s an interesting point as to why obscured observations would be avoided.
I can see the logic behind the position and the rationale for taking the position. Not something that would have occurred to me when it comes to obscured locations in general.
To clarify and make sure it is absolutely known what I was saying (and also to make sure the censorship of my comments does not lead to mis-statements of my position): I was drawing a distinction between obscured observations and observations with no location information at all.
The former I believe there are legitimate reasons for. Privacy is a big one and protection from poaching is another big one. There are others.
The latter I do not believe there are legitimate reasons for doing deliberately. Since I do not believe there are legitimate reasons for completely missing out location information from any observation uploaded to iNaturalist, the simplest and most effective solution to the issue is simply to put in code which does not allow the creation of observations without any location information. That deals with both those who do it deliberately and also with those who do it accidentally. The latter is simple error, and the mitigation for error is making it impossible for the error to happen in the first place.
I have seen people use private locations in the case of extremely sensitive, critically endangered species which face immense persecution. I think this being an option is valuable, especially if there is only a small amount of plausible habitat in the obscuration rectangle which matches the background detail in the photo. I have also heard it is possible to still access the coordinates of obscured observations, but people are understandably hush about specifics (though I’m really not a fan of security by obscurity and think this should be addressed). I have seen people put enough notes about locale in the observation notes for them to still be identifiable. I do think the site could do a lot more to communicate why it might be a bad idea to set the location to private as I see new users using this feature in ways that make me suspect they don’t understand why this might make their observation much less likely to be identified, or misinterpret it entirely (since it’s phrased as “location is… [private]”, some seem to misinterpret this as a way of flagging that it was on private property).
That being said, as there are legitimate use cases for private locations, as they represent a minuscule fraction of the content on this site (a third of a percent of verifiable observations) and as they are easily filtered out, I don’t see why the feature should be removed.
Its also easy to request the observer changes it to obscured instead of private! I usually ask if the species needs geodata to determine (Like GBH vs Grey heron or most magpie species)
sigh this again brings up the difficult discussion of identifying just based on range versus using range to help with field marks. The Great Blue Heron (GBH) and Grey Heron can be identified by field marks alone (Great Blue Herons and Grey Herons have been found together), without relying on geographic range, but of course it is very useful help to use in conjunction. Basically, always take a close look as opposed to identifying without a second thought. I don’t wish to get further into this in the thread, but I just want to add a word of caution on automatically identifying with range and not looking at the marks as some would say what is the point of making the id yourself if you are just identifying based on expected range when any non-expect could do that and be equally wrong. As an example, I am someone personally working on a subspecies guide and this is what all experts I’ve seen recommend as the approach for bird subspecies.
Maybe ask the person if they are okay with their info going unobscured to a third party? For example if it was just a few observations it wouldn’t be obvious that the location was my house so I would be okay with it being shared with a third party. I do observations on the side of random roads, but there are just soooo many at my house that it’s obvious that that’s where I live so I obscure those.
poachers. I obscured my recent batch of observations because it included a timber rattlesnake–which yeah, gets poached sometimes. I’ve thought about going back and obscuring a lot of Kinosternidae observations after hearing about poachers targeting mud and musk turtles for the pet trade too (and seeing some tables at a reptile show that just looked/felt sketchy).
I get on the order of 40-50 thousand observations from iNat every year for inclusion into our database (plus a few thousand from other sources). I can barely keep up with IDing the unobscured observations. No time for contacting individual observers and then reading explanations for why they had to obscure a particular observation, keeping track of who has and who hasn’t been contacted, etc. etc.
Periodically, I have a look at the obscured observations just to see what we’re “missing”, and frankly, it’s pretty mundane. I rarely see anything of even passing significance.
Our database predates iNat by about a decade. We’ve had to deal with concerns about privacy and threatened species before these issues came up on iNat. But folks on iNat takes things to a whole different level.
We debated it for a while, and in the end I just said no - if someone’s personal safety is genuinely in peril, I don’t want that kind of responsibility.
I know someone who has posted pictures of rattlesnakes on Facebook and advocated blowing the snakes away with a shotgun, regardless of what they are doing. Suffice to say I did not react well to that person’s attitude to rattlesnakes.
That person embodies another attitude that justifies obscuring of exact observation coordinates: cruelty to animals based on utterly illegitimate attitudes. Cruelty in this case being blowing away with a shotgun. I do NOT want to see a person with that kind of attitude be able to persecute the species based on iNaturalist observations.
But that doesn’t cover all the options iNaturalist provides. The location can be public, obscured, private, or missing. Private locations are visible to the observation owner (or the curators of projects), but hidden from public maps - so they effectively have no coordinates at all for other users. Obscured locations may be an aid to privacy (loosely speaking), but they aren’t strictly private, since they still appear on public maps (albeit with fudged accuracy).
Private and obscured locations provide no security guarantees whatsoever. The only way to achieve that on iNaturalist is with missing locations (assuming the user took all other necessary precautions with the observation data they uploaded). I don’t know whether any users actually employ this level of security with their location data, but it doesn’t seem unreasonable for iNaturalist to allow it. The trade-off is of course that the observation can never become research grade, unlike with the other three options. GBIF accepts research grade observations with public, private (i.e. absent) and obscured locations.
AFAICS, iNaturalist is covering all the bases here, so there’s no pressing need to remove the ability to create observations with no coordinates. It can afford to cast its net very widely, since it’s explicitly not designed to act as a data-repository. If people choose to ignore that and treat it like one anyway, the onus is on them to cleanse whatever data they export accordingly.
Many users don’t know they can set the privacy, or may have experienced an error during upload.
I usually just paste the Frequent Response’s missing location text (or type “missing location” if I’m in a hurry or have already pasted the full boilerplate into another of their observations) into a comment and then largely forget about it. Either they’ll see my reply and add a location or they won’t, but at least now they know why they haven’t been getting IDs.
If they reply it’s for safety, I tell them they can set it to private and then I move on, because either that answer is enough to reassure them or it’s not, and that’s valid for whatever their lived experience may be.
In which case sanity-checking code should catch the error and stop the creation of an observation on the server, returning an appropriate response to the client software. Said client software should show a note saying that upload failed due to an error and to try again.
Alternatively a draft observation could be created on the server with a status code indicating to the client that upload of coordinate information is needed before the observation is fully saved.
Errors happen with systems like this. Mistakes occurs for users. The trick is stopping as many of the errors and mistakes as possible via sanity-checking and bound-checking code.
