Enlarge all place bounding boxes slightly

Feature Requests
1

Projects with small places often don’t capture observations due to the accuracy circle breaking the bounding box. The suggested work around seems to be make it a traditional project. The observations still need to land within the place.
https://help.inaturalist.org/en/support/solutions/articles/151000169942-why-is-my-observation-not-showing-up-in-a-place-or-collection-project-i-know-i-observed-it-there-

Suggestion: instead of having the bounding box tight up against the place - add another 100-200 feet in all directions. Enough to capture observations with not uncommon accuracy, but not so much to include observations with HUGE uncertaintity.

The other thing to keep in mind is that if I’m inside a place, but my subject is outside it, the observation will get included (assuming accuracy is OK). The GPS in your camera has no idea where your subject is - it locates the GPS receiver (photographer). So this notion that its important to exclude observations that don’t belong based only on accuracy and place geometry makes little sense. You’re probably already getting observations that don’t belong.

eg: compare locations vs images - almost all of these appear to have photographed from the shore, but the subjects were out in the ocean - do they belong?
https://www.inaturalist.org/observations?place_id=109417&subview=map&taxon_id=152871

1000003639
10000036391080×1325 218 KB

1000003644
10000036441080×600 66.8 KB

2

I don’t think this would be a good idea to implement. 100-200 ft (30-60m) is an absolutely massive amount! For backyard projects (in European cities, at least) this would then basically include the whole block. In iNat-active places, it would collect lots of observations from outside the project area, which seems to me a worse problem than some obs not being collected. If you know the exact location of an observation, you should just manually edit the location and accuracy radius for them to fall into the project area. (If the observer definitely knows the observation happened in a relatively small place, I think they should be able to get the uncertainty radius to single digit (in m)).

I think, a better way to achieve this is allowing project admins to manually approve observations with the pin inside the project area, but the accuracy radius breaking the boundary.

2 Likes
3

Why not do this to the place?

3 Likes
4

Yes, I think this request essentially takes a problem that affects a few projects (that is solvable be them altering the boundary as they need as you point out) and proposes a change that would have non-intuitive and potentially detrimental effects for all projects. Changing the bounding box calculation method would lead to large scale changes in which observations are included in most projects on the site overnight whenever the change would be implemented, over maybe over weeks since it seems like it would require reindexing all observations (I would think). It would render accurate comparisons of past projects results with future ones impossible.

I would also note that the accuracy circle already does have some tolerance built in vis a vis the location boundaries via the bounding box, see: https://forum.inaturalist.org/t/uncertainty-radius-crossing-the-project-border-but-still-included-in-project/60940

5 Likes
5

I do, many do not.

6

So you’re talking about observations of other users in projects you don’t manage using places you didn’t create? Can’t you make your own places/projects if it’s that much of an issue?

7

I could, but this issue keeps coming up and i’m not sure creating duplicate places is a better solution.

2 Likes
8

The observations would still have to fall within the place, so it wouldnt add those.

1 Like
9

FYI, not always true. At least in the old Apple app (I don’t like the new iNat Next app and haven’t explored it well), this is impossible. Zooming in as far as possible still limits the radius to 22 m. You can manually enter a smaller number in the accuracy field if you want, but the app’s own user interface won’t make it happen.

And it’s a red herring for this request anyway-- why should observations on the edge be held to a higher standard? People are presumably following their own best practice on all their points, and may not even know about whatever boundary is of interest to a random iNat project.

I think I’d agree with this.

I agree with this-- lots of duplicate places gets annoying and confusing.
At any rate, don’t forget to vote for your own proposal!

1 Like
10

It’s a bit unintuitive but in iNat Classic on iOS by twisting the map, you decrease the radius. That way you can get uncertainty down to 1 or 2 meters

1 Like
11

I just can’t imagine anyone doing this. Does anyone actually look at a project and go to the trouble of seeing what observations fall within a place but the accuracy circle breaks the bounding box? GPSs have uncertainty - why should observations near place edges along bounding boxes be held to a higher standard?

1 Like
12

Wow, I’d never figured that out even after thousands of uploads… Thanks!

1 Like
14

I disagree, the current setup is non intuitive and affects all projects to some extent. I don’t think the average user appreciates how the bounding box works and why some of their observations aren’t making it.
If i understand it, the bounding box is defined by two points - it shouldn’t be too hard to move them a set amount to the ne & sw.

15

To be fair, I think before the edits, this was about observation places, rather than the bounding box (or at least, it wasn’t clear to me, and I wasn’t aware of the exact mechanics behind this before cthawley’s post). Extending the bounding box is a substantial difference from extending the project place boundaries and from a data-quality perspective I wouldn’t have a problem with that.
But cthawley has also already said why this change would be problematic/unrealistic to happen. I have no idea how any of this works, but knowing that places are quite taxing on iNat’s infrastructure, mass-editing all existing places in all existing collection projects, I can see that there might be issues with this approach.

In general, I agree with you that observations not being part of a project due to their radius is a problem that should be solved, but if enlarging the bounding box is not the right way to go about it, I could envision a feature whereby a list of observations that meet the criteria (pin in observation field, uncertainty radius beyond the bounding box) can be seen by project admins on the overview or observations page. Then it would just be a matter of going through them and accepting them manually.

Yeah, it’s quite obscure. I also just figured it out “by accident”. You’re welcome :)

1 Like
16

The title never changed and the first paragraph wasnt edited - this was never about enlarging places. I don’t think most people understand how this works - you never actually see bounding boxes. Maybe we should be able to see them!? Maybe as an option?

17

I apologise, then, and thank you for adding more context. I think being able to see the bounding box, as you suggest, is a good idea. In any case, I won’t be imposing my opinions this thread any longer, as I don’t think anything I can add will be of any substance.

1 Like
18

No apology required, but it does illustrate that this is something ALOT of users don’t understand.

19

I have created many Places over the years to address this issue. Of course, this “solution” then causes other problems.

It causes duplication of existing Places, whether “official”, imported from an authoritative source, or created by other users. This makes Places harder to both search for and select from the conflicting/overlapping choices.

I have to supply iNaturalist the KML to create the Place. I have to create that in some GIS program. Since I don’t use any of the available ones to create maps, only view others’, I use Google Maps to outline the area. This is time-consuming and error-prone.

I can imagine automagically creating a buffer around Place boundaries, depending on their characteristics. Small areas - such as my garden, community gardens, etc. - need a larger buffer as a percentage of their dimensions and area. Areas with complex edges, such as EcoRegions, need to be “smoothed” so Observations don’t fall between the fiddly bits. Multi-area “boundaries”, of which Ecoregions are often good examples, may need to be covered by a single simpler area for Observations that show up “in-between”.

Such a solution might help, but it can’t solve the underlying problem of GPS device accuracy (not iNat “accuracy”, which might be better thought of as “location confidence”). I live in Brooklyn, and do most of my naturalizing in and around New York City. GPS accuracy in developed areas, especially where the sky is obscured, are unreliable.

In New York City, “places” are small. I created a Place for my garden. My property is 50’ x 100’ - huge by NYC standards, tiny by comparison with other NYC properties, even many NYC playgrounds.

To get most of my observations showing up, I had to set a huge error boundary, 20-25 feet, 25-50%, on all sides. Even if the Location point is in bounds, if the Location Accuracy is too large they won’t show up as in the Place. I can manually fix those Observations by reducing the “accuracy” to a smaller proportion of the dimensions, e.g.: 20’ → 5’. Even then, many of my observations are still placed in a neighbor’s yard, or the street. If I notice them, I have to manually edit them to correct the location.