Editing Pre-existing Location on iNat

I have a project on here (https://www.inaturalist.org/projects/sleeping-giant-state-park-biodiversity?tab=observations&subtab=map) and I am running into an issue with auto-population of the collection project from certain users. What I am seeing from searching the forum is that the “uncertainty circle” of the observation is falling outside the place boundary so it is excluded.

Example: https://www.inaturalist.org/observations/37288543
This is in Sleeping Giant SP and fullfills all the criteria except the red circle around the observation is larger than the project boundary (Mt. Carmel Av is the southern limit).

Now I did not create the project boundaries so I can’t modify the boundary of the place but is there a way I can modify the “location” of Sleeping Giant State Park’s default circle so it falls 100% within the actual park? I see the red circle is quite large and extends >195 meters around the observation. This default location and circle can be accessed on the upload screen as a type in location and gives the same results every time so every observation using the “Sleeping Giant State Park, Hamden, CT” location will get the same centroid/red circle and will be excluded from the project. I know users can make the circle smaller manually, but we are trying to make the upload process as easy as possible for outreach purposes and it would be far easier if the default uncertainty circle was 100% within the park project!

I hope this makes sense but I don’t see any way to access/edit the default centroids and red circles for various parks in the iNat database. So basically I want the location to have a smaller red circle, and save that so other people can use it as a default for the park.

By “I did not create the project boundaries”, do you literally mean project boundaries, or the boundary as defined within the place? If you created the project, and set one of the rules as “must belong in = This Place”, and that place was created by somebody else, then you are right, you can’t edit the boundary. But what you CAN do is create a new place based on it and use that in your project instead.

I think you can export a kml file of the boundary in that place, and then create a new place and upload the kml file to it, then adjust the boundaries as you see fit (I usually go 50m or so outside the “official” boundary). When I create these additional places, I call them “This Place (and surrounds)”, so that they come up in the same searches in places etc. as well as being clear what the difference is. Then just change your project to include observations from this new place rather than the “official” one.

If, on the other hand, you have no access to changing the criteria for the project, then it’s really only able to be done by editing observation pin location and accuracy values, which may or may not be possible, and may or may not be acceptable from a data validity perspective.

1 Like

Assuming the suggestion I gave above is not suitable for the situation, another possibility might be to create another iNat point place (ie one that doesn’t have a boundary, but is just a single point on the map, located more centrally within the park, and have observers enter that location name instead. Still not ideal though!

I just experimented with a similar situation near me… Eastwoodhill Arboretum. The place exists as a bounded place, and when I enter the name in the location field of a new observation, it comes up with the pin location inside the boundary but not centre, and has an accuracy circle of 116m (not as a whole number though). When I edit that location, I can’t find anywhere that I can change either the pin position or the accuracy value. The differing values would suggest it can be set, but the decimal portion also suggests that it might be relative to latitude (smaller values nearer the poles). Or perhaps it is a factor of the zoom level in the map at the time the place was created.

It’s possible that staff/developers might be able to edit these values directly, so I’ll tag @tiwane and @kueda to see if they can do so, at least as a solution to your immediate problem

[further edit]
I’ll add that for Eastwoodhill Arboretum, the default accuracy and pin location has the accuracy circle completely within the boundary

It’s true there are workarounds, but I’m also curious about a solution to the root cause. Searching for “Sleeping Giant State Park” by default gives you the lat/long 41.42/-72.90 and an accuracy of 195. Where is the original source for those values? And can they be changed?


That’s on the app? I’m guessing the lat/lon and accuracy values have more decimal places, and that they are rounded for display in the app. Probably are rounded for display in the browser as well! I see them at about 6dp (8 or 9 sig.fig.?)

i suspect these come from Google, and you’d have to ask Google to change it. see https://forum.inaturalist.org/t/butte-county-bounding-box-incorrect/8034 for something similar.

Yes, jwidness, thanks for the image. It illustrates the project boundary issue well

Do you know how I could make a new point location? If I did make one the old one would still be there so in an ideal world I could just replace the old one instead of having two of them with the same label. Even if they have the same centroid, the large radius of uncertainty is the issue.

Of course experienced users can work around this by editing the radius on uploading, but I am more concerned with people who use the “stock” Sleeping Giant location with the large radius and don’t look back. Also the backlog of observations of which hundreds could be suffering from this issue!

I thought we could create point places, but my experiments reveal that it looks like we can only create bounded places. Perhaps create a new bounded place that encompasses the portion of that accuracy circle that is outside the boundary, and then include that extra place in the criteria for the project. It’s messy, but accomplishes the goal

Well not sure of I understand what you want to do, but the uncertainty circle is linked to the accuracy as determined by the GPS sensor, which is linked to the number of satellites locked and their position. I believe it is there by design and has to.
The only solution I see is that the user overrides manually recognizing the position on the satellite view by editing the location and - on the mobile version- zooming in as much as required to validate the accuracy.

Yes that seems to be the only solution at this point to manually shrink the circle down to be entirely within the project area. I guess the majority of projects don’t have their GPS centroid that close to the edge of their park but it is frustrating when we potentially have a lot of user observations from the past that have this issue and won’t show up in the project because the uncertainty circle is outside the park.

I could try and do what kiwifergus said to try and salvage some of those observations

if you have that edited on the desktop version, it’s a bit easier, as you can set up the accuracy manually. Obviously you have to adjust the position too, un case it falls outside the project area and you are sure it fell inside instead.
I usually do that “easy” by pinning a location inside my boundary and using it (by recalling it) to relocate the obs pos close enough to avoid dragging the marker for kms.
It happens when some of my obs have a poor gps accuracy (kind of 5km) when usually is 4mt instead

First, some explanation, since there seems to be some confusion here. Whether or not an observation is “in” a place, e.g. it will turn up in place-based searches or collection projects with place filters, depends on a couple things

  1. The coordinates of the observation must lie within the place boundary
  2. The place must be a country-, state-, or county-equivalent (admin level 0 to 2 in internal jargon) OR the place’s bounding box must contain the “positional accuracy” circle of the observation

Note this has nothing to do with the place’s centroid. Here’s an illustration of this example with the observation’s positional accuracy circle in red, the place boundary in blue (aquamarine), and the place’s bounding box in light green:

So this observation’s accuracy circle is right on the edge. Does the bounding box contain it?

Nope. So, why are we doing this: the accuracy circle means the true coordinates could be anywhere within that circle. If the circle includes areas outside the place boundary, that means we don’t know if the true coordinates were inside the place or not. I would prefer to just not return it in place searches at all at that point, but if I remember correctly, nobody liked that, so the admin level and bounding box things were compromises.

What should you do about situations like this?

  1. Accept the fact that you don’t really know if these observations were inside your project boundary or not
  2. Encourage people with observations like this to be more precise when setting coordinates
  3. Add a new project-specific place that encompasses your entire area of interest. Your approach of adding an additional place works. I think what I would have done was just to make a bigger version of Sleeping Giant and called it “Sleeping Giant Biodiversity Project Boundary” or something
  4. Make a traditional project and encourage volunteers to add their observations manually

Please don’t edit the existing place boundary. Making the place boundary inaccurate to suit the needs of your project just messes up the boundary for everyone else.

Colophon: it’s been a while since I had to do anything like this in QGIS, so I thought I’d note that attribute-dependent point scaling requires a CRS with units set to meters (e.g. UTM), and that QGIS has a handy bounding box tool.

1 Like

@kueda can you confirm that the default lat/lon and accuracy values are coming from Google? Would asking them to change be a possible solution?

I made the boundary place to accomodate that little bit of circle that falls outside the place. Given the State Park abuts a College, it is more likely that the observations are in the park part of the circle and not the lawn on the other side. And if there are a few from the edge of the college campus it’s not the end of the world as the species is likely in the park too.

I suppose I could manually add a large polygon encompassing the whole darn thing and be done with it, but the place map is very detailed and good and I don’t want to include residential yards and stuff. So I think additng that little extra chunk across to Quinnipiac is the best solution.

I think there might be another level of confusion here, too…


Both suggest that the issue is when the observer types in the location name in order to locate the pin. This to me implies there is no GPS involved at all… A savvy user will enter the name, zoom in, move the pin to where it was actually seen, change the accuracy value… but a less than savvy user will type in the location name thinking that is all that is needed, and submit the observation.

For Eastwoodhill Arboretum, as an example, this works fine both ways, because the default pin location and accuracy value that results from just entering the location name is fully within bounding box. In @rayray’s place this is not the case. Is there a way to change the default pin location for the place, and/or it’s accuracy circle?

1 Like

I’m not sure what you mean by “default,” but if you’re referring to the accuracy value that gets set when you search for a location by name, it depends on whether you’re using the Uploader on the website (Google), the Android app (Google), the iPhone app (Apple), or Seek (Google or Apple, depending on the operating system). These services generally return a bounding box (i.e. a rectangle) that they think encompasses a location, which we use to set the positional_accuracy attribute. I suppose you could complain to them if that seems inaccurate.

In the case of https://www.inaturalist.org/observations/37288543, the “Locality Notes” are 200 Mt Carmel Ave, Hamden, CT 06518, USA, which seems like an extremely unlikely piece of text to type by hand. Since the observation seems to have been added via the website, I’m guess the user manually clicked on the map, which sets the accuracy circle to a value that’s relative to the zoom level ( (1 / 2^zoom) * 2000000 to be exact).

Exactly – in the screenshot I posted above from the Android app, you can see the lat/lon and accuracy (41.42/-72.90 and 195) that were returned to me when I manually typed the location as Sleeping Giant State Park. It looks like Google is returning the park headquarters when you search for the park, and the bounding box is big enough to cause the accuracy to leak out of the park a bit.
I’m guessing we could ask them to either move the point further into the park (which could potentially screw up their navigation instructions, so they might not like that), or to make the bounding box smaller.

1 Like

In the Eastwoodhill Arboretum example, I enter “Eastwoodhill Arboretum” and the locality notes get filled in by… Google?

Perhaps google is just providing the nearest “named place”, which would be from titled sections in these cases? The pin location might not be centric to the bounded area sought, but could be centric to the nearest legal title.

Ok, it is not legal title centric, this shows Eastwoodhill Arboretum title boundaries, the red mark is where the “default pin placement” goes if you enter “Eastwoodhill Arboretum” as a placename:

However, the default pin location is directly adjacent to the property entry that a google maps “directions” would send you to.