This is one of the limitations of the newer projects that add observations automatically based on location, especially if it’s a small location. If you’re trying to collect all the observations from a small piece of land for something like a bioblitz, it’s sometimes better to use a “traditional project”, where observations are added manually. That way any observation that you know was made within the project boundaries can be manually added, and project curators can decide for themselves to include or not include things. The automated projects that most folks use today are easier to manage, but they will always suffer from data imprecision around the edges of the designated project boundary. And if the project area is very small, this can be a major problem.
When I’m out with my camera gear taking multiple images of things, I will usually take one photo on my phone with the iNat app as well. That photo is generally not as good as my camera will produce, but it has the GPS coordinates and accuracy included.
Then when I’m back at the computer editing my images I can add the best ones to that record. That gives me the convenience of the iNat app for locations, without slowing me down when processing my camera images.
Another benefit of using the iNat app is you can see your point on the map as soon as you make it. That’s often the easiest time to correct it - moving it out of a lake and back onto a trail, and increasing or decreasing the accuracy circle as appropriate. Sometimes the GPS-based accuracy circle can be quite large, but the satellite image clearly shows a landmark that allows me to reduce it.
But why on earth would you enter observation locations this way? Yes, the feature is available, but as you have surmised, it’s a suboptimal way of entering locations. It’s not the automatically generated location that’s asinine, it’s the person who chooses to use it.
How on earth is iNat supposed to know exactly where you made an observation? Only you know that. If you enter a location based on a place name, then that’s necessarily going to be an approximation. It cannot be anything else. There’s no point in disparaging it - it’s there for the convenience. Yes, those who use it should make whatever adjustments are necessary, but many don’t. I find it frustrating when I see regular contributors repeatedly using it without making adjustments, and I know for certain that their observations were not made within the circle specified, but were made several hundred meters outside it.
I don’t have a lot of familiarity with how places work when entering observation locations, and whether the places accessed when you type in a place name are the same places you see when you look up the list of defined places. I’ve looked at the list of places for Ontario, Canada, and a lot of the polygons are wildly inaccurate. Sometimes there are multiple versions. I meant to do some testing with using some of the bad ones to see what happens if I try to use them during data entry, but I never get around to it. I don’t actually submit many of my own observations to iNat.
I wish more iNat users were using the web interface, and entering location data in a conscientious fashion. But like it or not, most observers use their phones, or some other method by which lat/long gets automatically recorded in their photos, and they don’t give it a second thought. They don’t even notice if the location is way off unless somebody else tells them (ie. someone who wasn’t even there at the time the photo was taken).
To my mind, this is a much bigger problem than the size of the accuracy circle which the original poster complained about. I use data from iNat and what I’m concerned about is whether the accuracy circle contains the true location. The size of the circle isn’t a big concern for me, as long as it isn’t ridiculously large (opinions differ on that threshold).
And I wish it was called coordinate “uncertainty” rather than “accuracy”. (having a big number for accuracy is undesirable, which is counterintuitive for most people)
They are not the same. I don’t think the result you get when you type a name on the map when submitting an observation is related at all to the various place “polygons”. Many parks that don’t even exist on iNat as places still show up when you type them when adding location observations via browser. I think what shows up is just the location you get from a Google Maps search.
On a related note, you can always flag iNat place polygons if they’re incorrect. I’ve done so for several of my local parks and they were replaced with improved polygons. But these polygons being incorrect shouldn’t impact where locations appear when searching the map while adding observations.
Most modern cell phones have very accurate GPS units built into them. Under certain circumstances, that accuracy may be compromised (interference from nearby buildings, trees, mountains, etc.), but in general they work quite well. Unless you go out of your way to disable location services, etc., the lat/long coordinates get recorded in the EXIF data of any digital photos you snap with the phone. iNat automatically detects and uses this location data when the photo is submitted as part of an observation. This is how many people make iNat observations - they have no direct interaction with the location information.
Even folks who use digital cameras often have a variation of this mechanism. Their digital camera may have a build in GPS unit similar to what’s in a cell phone, or the camera may communicate with the users cell phone via bluetooth and get lat/long data from the cell phone. Either way, the camera will record the lat/long in the EXIF of the photo, where iNat can find it when the photo is submitted. This can be less accurate than when the photo is take with a cell phone because if the location data is relayed from the phone to the camera, there’s an opportunity for the camera to get “stale” location data. Nikon cameras seem to be prone to this.
Another method some folks use is to have a hand held GPS unit record a trace of their route during their survey. They ensure that the clock in the GPS unit is exactly syncronized with the clock in their digital camera. There are apps that will take the timestamp recorded in the photos from the camera, compare them with the timestamps in the GPS trace, and estimate the lat/long where each photo was taken. I originally found out about the Nikon problem when I pointed out to someone that they had photos of the same organism (in the same context) as another iNat user, but at a different location. They said “yeah, we were all in the field as a group. The other guy’s Nikon camera often records the location of the previous stop we made.” I had assumed it was the other guy’s location data that was accurate, because it had been recorded directly by the camera (as visible in the photo EXIF). Since then, I’ve noted something similar happening with a friend who uses a Nikon camera. He’ll submit images to iNat that have the wrong lat/long (which I know because I was there and know where he photographed the organism in question).
In summary, none of this is foolproof, and it would be nice if folks double checked the locations recorded in their observations before submitting them, regardless of which method they use.
While it’s great that iNat supports a variety of ways to enter observations, and therefore can accommodate a wide range of observers with idiosyncratic work flows, it means that it can be hard to guess what went wrong when something doesn’t look right. You have to do some digging to figure out exactly what the observer did, and then try to troubleshoot what might have gone wrong.
Thanks. Good to know.
This is what I do as well, but generally, my observations don’t go into iNat, so I don’t have to worry about it.
I think what you’re doing is GOOD, because you are consciously choosing the uncertainty radius based on where you know you went. Someone is going to complain that your data is “useless” because the size of the uncertainty radius is (in their estimation) too large, but at least your data is correct. You know for certain that your observation occurred within the specified uncertainty circle. I don’t think this can be said for a lot of observations on iNat.
Personally, I think this is a flaw in how the collection projects are set up. I don’t think the uncertainty circles should be factored in, but that’s just me.
Earlier today, I did notice that for the project I work on, this doesn’t seem to happen (I identify observations for the Ontario Butterfly Atlas project). I only look at observations that are part of the project, and this morning I noticed one that was close to the US/Canada border. The uncertainty circle encompasses some US territory, yet the observation was still part of the project. I doubt that the observer added the observation manually, but I guess there’s a non-zero possibility that this occurred. But it’s an old project, so maybe it works differently from more recent collection projects.
I’m not sure how exactly they’re factored in, but I’m pretty sure I’ve seen them be excluded if the circle is too big. After all, if someone drops a point in my yard with a 100 km accuracy radius because they saw the organism “somewhere in central Pennsylvania”, I wouldn’t want that going on my yard list. They just clicked a point somewhere in the state and expanded the bubble to include the area where they might have been. There are lots of huge bubble observations with a meaningless central point, and excluding them from projects that focus on that central point location is desirable, in my opinion.
My understanding is the exact rule is that the pin must be in that place, and the accuracy circle must be entirely contained in the bounding box (the smallest rectangle containing that place with sides oriented along the cardinal directions) for that place.
I assume using a rectangle of latitude/longitude lines is faster than, say, a buffer around the place.
Perhaps the onus could be shifted to those managing the projects to exclude observations they feel don’t belong. For example, with the project I work on, observations with an uncertainty > 10km are part of the project on iNat, but that’s as far as it goes. They don’t end up in our actual database. But I manage that exclusion myself - I don’t expect iNat to do it for me.
Thanks. That would explain it. The location in question would have been well inside the bounding box. I might try adding a test observation to a location near a different edge of the province, where the uncertainty circle would fall outside the bounding box to see if it gets included in the project. If it does, it might mean we are missing some observations that occur near the Manitoba/Ontario border, which would define the western edge of the bounding box for Ontario.
Well, if you understood my preferred workflow, then perhaps you would not still think that I am so asinine.
Here is an example of my workflow.
I go to a given place - let’s say this time it’s the Franklin Parker Preserve in the Pine Barrens of central New Jersey. I go there and search for all kinds of wildlife, and take a few hundred photos of whatever I find, with my specialized photography gear. Birds, mammals, insects, reptiles, etc. And then I come home and spend the next 3 or 4 days downloading, selecting, scrutinizing, and editing all of the photos. And then I often want to post a dozen or so of the photos to iNaturalist as observations. So I get on my real computer with the nice big 5k Retina display, go to the iNaturalist website, and upload the very best photos of each species that I was able to get quality photos of. I go to the location search bar, and start typing “Franklin Parker Preserve”, and then once I type about half of the name of the place, I see it show up on the pop-up results box, so I select Franklin Parker Preserve as the location by clicking on it. Then I see that the default location circle is pitifully small, and only includes, like, the parking lot. So I expand the circle to include the entire part of the preserve that I photographed in. Then I pin that location so that for all of the other observations, I will not have to type the name in and adjust the circle anymore … do it once and pin it, and then I can just select Franklin Parker preserve from my list of pinned locations and the custom-adjusted circle will be good for all of the observations from that outing.
This works great for what MY purposes are for my own observations. All of the observations are accurate, as they all lie within that circle that I made. But they are not necessarily precise, and that suits my purposes, because I don’t necessarily want people to see exactly where each observation was, especially with things like trophy-caliber big game animals, because of the possibility of poaching, or certain herps, such as rare rattlesnakes, because of illegal collecting for the pet trade.
Doing things this way suits all of my purposes perfectly, so it is not so asinine from my perspective. I am not doing iNaturalist for scientists and researchers. They are not part of my purposes for using the platform. If they happen to derive any benefit from my observations, then good for them! But I have no intention of adopting a workflow that doesn’t work so well for me, just to possibly maybe make something easier for someone else someday in the distant future. That is not of importance to me.
EDIT: To be clear, I know exactly where (on a map) I have take every picture and seen every animal I have ever photographed. I do not need to reply on built-in phone or camera GPS systems because I can jump on any computer, go to Google Maps, and find exactly where I saw every animal I have ever photographed within 60 seconds. If I come back from an outing with 1,000 photos of 50 different animals, I would be able to tell you precisely where each and every one of this 50 animals was. Even years later I can remember right where everything was. So I am not being inaccurate with the way I custom adjust the circle on the website - every single observation will be within that circle. No guessing.
What @rcavasin is calling asinine is the idea that a user might stop the process here and just leave that as the location without actually dragging the point to where they were. I don’t think anyone here on the forum would do such a thing, and I hope that no one ever just leaves that point/bubble and calls it a day.
Most users are inputting their locations automatically from their photos’ location data. Some are clicking on the map where they know they were at, as you seem to be doing. Either of those is fine. I think the point being made is that the location and bubble that show up when you type FPP into the search bar should never even be considered as the final location/bubble to place your observation. We all agree on this point. I think there’s confusion on this thread because unlike the random bubble that appears when entering the name of a location, the bubble that appears for geolocated phone photos actually does mean something, ie it’s a measure of the phone’s certainty about where the device was when it took the picture. So while calling the bubble arbitrary and ignoring it is reasonable when entering a location your way, ignoring it and shrinking it randomly without further consideration is not a good idea when dealing with a bubble generated by the camera device itself.
I never said you were asinine. As far as I can tell, you were the one who started throwing around that term (in reference to the default uncertainty radius provided when you enter a place name into iNat).
Your workflow is pretty much identical to what my own workflow would be if I were putting observations into iNat. I generally skip the middle man and put my observation directly into our regional database, and my geolocation process is pretty much identical to yours. The only exception is that I don’t generally type a place name into a mapping app since most of the places I survey don’t have official names. I just find the location on satellite view, pick an approximate centroid for the route I followed in my survey, and measure a radius from that centroid that encompasses the survey.
So obviously, I don’t have an issue with how you’re entering your data. The only issue I have is with your disparaging remarks about the default lat/long and accuracy figures that iNat provides when you type in a location name (you refer to it as asinine).
And for the record, I don’t agree with the original poster - I think his argument is rubbish. Just because he can’t find his observation locations on a map doesn’t mean others can’t. As pointed out by paul_dennehy, I’m calling out the folks who type in a location name and then use the default lat/long and uncertainty radius that iNat provides. I would also take issue with folks who blithely accept the location data recorded by their devices without double checking their accuracy.
Of all the various approaches to entering location data that iNat supports, I would favour yours (no surprise, since it is the same as mine). You are in control, and aware of what is going on. There’s less likelihood of the kind of “silent” error that can occur when the lat/long is filled in automatically.
But clearly, there are some who disagree.
As much as I and many of us value accuracy and precision, I think it is also worth remembering that a lot of older specimens in natural history collections only have county (or state!) locations recorded. So the parking lot coordinates of the actual natural area someone visited are still providing more useful information than that, even if the accuracy circle is way too small as-is.
Anyone doing an analysis that depends on very precise geolocations (like species niche modeling) should already be checking their data for weird accumulations of individuals at the geographical or organizational centers of parks, counties, states, etc. But the locations still only have to be precise enough to fit accurately within the (often much) lower-resolution environmental data. And if someone is doing a lower-resolution analysis (like the bumblebee paper in a recent Forum post that used 10 km x 10 km grids), most small natural areas are going to fall entirely within a single grid cell. I can think of some research questions where it really would be important to have 5-10 m resolution of organism locations, but almost all of them are population management or behavioral questions where I would expect the researchers to be doing some of the monitoring themselves.
has anyone actually reached out to the observer to find out if this was actually what happened? nobody other than the observer would really know whether any adjustments made to an observation were reasonable or not, right?
i think it’s better to assume innocence than guilt. so i think any conversation that starts by assuming guilt is going to be unproductive. i would even say it’s probably time to close the discussion.
For Bioblitzes, I prefer collection projects where i only filter on date & observers. Collection projects don’t actually require places. This acts much like a traditional project, but doesn’t require moving observations. I get all the observations from the observers on the specified date - don’t need to worry about accuracy or bounding boxes, etc
I am assuming that in the case I mentioned the user did the correct thing. Slightly editing accuracy without messing with the true locstion. I started this discussion as I was irritated that data manipulation was recommended to fix a minor issue, without even mentioning that data manipulation should be done with care (and with data quality in mind).
I tried to make two points:
-
accuracy recorded by GPS is meaningful data. And
-
if we aim to produce scientific data, then using the iNat app on a phone with GPS, is a very good way to produce rather accurate location data.
I learned from the discussion that several people seem to have problems with the iNat app / GPS or maybe even GPS jamming. From my own experience, I see just a low percentage of wrong coordinates, but obviously the experiences of other users differ.
That’s a problem while recording. The solution to that (or to overly large accuracy) is: Stay in place, make a second observation giving the GPS more time. Delete the flawed observation. Deep ravines can remain problematic in my experience. Problems with data recording and GPS fix during recording is certainly something to look out for. When obvious this can already be corrected in the field. So in most cases this shouldn’t be a reason for data editing.
The second point this discussion reminded me about: scientific data doesn’t necessarily need an accuracy of 10m or less. A great percentage of my own records are plants in highly biodiverse tropical mountains. Here such an accuracy seems essential to me, in order to refind these plants. I certainly didn’t think enough, about far less diverse temperate habitats and highly mobile organism. And yes I am aware that many museum specimen do suffer rather imprecise location data. I don’t think this is the ideal we should aim for though.
let’s not suggest that other participants in that previous thread did anything wrong either.
when i read the posts from that previous thread, i don’t see any recommendation to manipulate data. what i see is more of a statement of fact that the recorded coordinates + accuracy value exceed the bounds of the location as recorded in the system.
in this case, the observer read that statement of fact and decided on their own to edit the location of their observation, but another observer could have read that same statement and chosen to do nothing, and yet another observer could have chosen to alter the place definition in the system. there are pros and cons to each approach. none of these is absolutely a good or bad approach.
if by “recorded by GPS” you mean recorded by some sort of GPS device, this doesn’t even appear to be how the user got their original coordinates and accuracy value. it looks more like they got those from geocoding “Jackson County Greenway”. if you do that yourself on a test observation using the web upload screen, you’ll get the exact same coordinates and accuracy value as are recorded for some of the user’s unedited observations from that day.
when a location is geocoded in the web upload screen, the coordinates and accuracy value will just represent the center point and radius of the smallest circle that fits completely around the Google Maps representation of the place.
i get the impression that a lot of people think that coordinates + accuracy values in the system are recorded in very standardized ways or have a very standardized underlying meaning. but that’s simply not the case. you can’t just assume that the location recorded in an observation will necessarily lead you to the spot where a particular tree exists, for example. that location is more likely to lead you to the place where the observer saw the tree from, which might be near where the tree is but might also be from the next mountain or across a river. or often, the location may lead somewhere completely unrelated because phones were never designed to provide locations that are accurate 100% of the time. and these are only 3 possible meanings of the location of any given observation. i can think of at least 10 other ways you could interpret various locations.
Oh, ok … looks like we are fairly likeminded with the location thing.
You wrote:
“And for the record, I don’t agree with the original poster - I think his argument is rubbish. Just because he can’t find his observation locations on a map doesn’t mean others can’t.”
It boggles my mind that someone may not be able to find where they were on a map. Maybe some humans are just born with a natural cluelessness about geography and visual representation; like an inherent weakness for that realm of things. For people who can’t just naturally remember where they were and be able to find it instantly in any map, maybe the phone thing is quite helpful. If I was like that I would probably rely on the phone’s location information, too.