Don’t include observations within standard places if the precision circle crosses the place’s bounding box

Feature Requests
1

Some background, copied from the FAQ, bolding mine:

… Each place boundary has what is called a “bounding box,” which is a rectangle of latitude/longitude lines that inscribe the entire boundary. For example, below in red is the approximate bounding box for Lake Merritt, in Oakland:

iNaturalist will not index an observation as being in Lake Merritt if either the observation’s accuracy circle or obscuration rectangle break that bounding box. We do this to prevent observations from being added to a place when there’s a chance they were not found there and, more importantly, to prevent users from narrowing down the location of an obscured observation. This means that if you have a Collection project for a small place, obscured observations as well as observations made near the edge of the boundary may not be displayed in your project and you may want to consider using a Traditional project.

Note that this does not apply to counties, states, and countries and their equivalents, which are “standard places” in iNaturalist (as opposed to “community curated places” that anyone can add).

Using the Lake Merritt example:

image
image429×514 116 KB

In the current situation, an observation like this with a precision circle that crosses that red bounding box of this community curated place will not be returned in a search for observations in the place.

But if Lake Merritt were a Standard Place (a county, state, province, country, or some special exception, like City Nature Challenge places), it would be returned as falling within that place. Such as in this ridiculous example:

image
image764×618 133 KB

An observation with the map pinpoint placed in Illinois, with an accuracy radius of a few thousand kilometers, will be indexed as occurring within Illinois, when the organism may actually have been observed in Alaska. (It shows up in the community curated Chicago Wilderness place because it was used as a place for the City Nature Challenge in 2018.)

The proposal is to remove this indexing exception for standard places - not for cases where the precision is very coarse due to obscuration, but due to other reasons, such as poor GPS signal or the observer’s selection.

After all, the precision circle is there to indicate just that - the observation may not fall within that place at all!

@loarie is there anything I’m missing about why this isn’t already the case? Something atlas-related or?

2

As long as the observer is able to override a low-precision GPS-generated circle when they know the location, this is reasonable. That’s still the case, yes?

3

The observer can always manually edit the locational accuracy value to reduce the size of the circle, yes. And indeed can edit the location.

1 Like
4

If this is to be done, then the bug where if a species is geoprivacy open, set to obscured and then reopened are in it sets the buffer to something like 30km needs to be fixed first.

5

Are there metrics (or anecdotal information) on how well understood and applied the user control over location and location precision actually are? I have some knowledge of GIS so it came naturally but how much attention does the typical user pay to these things?

1 Like
6

Not sure, but definitely a common enough point of confusion to have a few entries in the FAQ. There was some recent thought (CC @michaelpirrello) that there should be some friendly tutorials about how places / geospatial info on iNat works. Maybe move to a new discussion?

2 Likes
7

Just trying to get my head around the nature of the issue and possible implications.

1 Like
8

For example, do not say this observation is in Canada or Ontario because the buffer crosses into US territory. So this observation would effectively considered to be nowhere.

https://www.inaturalist.org/observations/39675832

Just as an aside, one potential issue for this is the borders used by the polygons the site uses for standard places do not align with the shown borders on Google Maps. There will be cases where according to the displayed map the buffer is entirely within one jurisdiction, but the definition of the standard place does not agree.

1 Like
9

It would be “in” North America, just not confidently determined to be in Canada vs. the US.

yeah, already a problem too - observations are sometimes indexed in the wrong place because of this

3 Likes
10

I’m aware of my newness to all this and don’t want to be a distraction but I have been puzzled by some of the underlying technical issues involved in this proposal since I signed on to iNat.

Is there a technical reason for the all or nothing approach to overlaps or is it just the way it’s always been done. Seems to me that something like a 95% rule (an arbitrary number for purposes of illustration) would address the main issues without leaving a bunch of perfectly reasonable observations homeless… Or perhaps I’m missing something?

1 Like
11

Yes, it’s a technical reason. It’s computationally expensive to figure out whether a point is inside an arbitrary polygon or not (it’s a lot less expensive to compute whether it’s inside a rectangle or box), even more expensive to figure out whether a circle intersects with an arbitrary polygon (or, equivalently, what the shortest distance is from the center of a circle to the nearest border of a polygon). Computing the percentage overlap is even more expensive than that.

Now, I say “expensive” above, but those are relative to each other. In absolute terms it only takes a few microseconds to do the calculations. The real expense comes from multiplying the cost of one of those computations by the number of observations, since the computer has to do one computation for each observation, every time someone does a query for, say, all the observations in North America. So the procedure is something like this:

  1. Check if the central point of the observation falls inside the bounding box for North America. (Very cheap.) Go to the next observation if it’s outside.
  2. (Obscured observations only) Check whether the obscuration box of the observation intersects the bounding box around North America. (Very cheap.) Go to the next observation if it intersects.
  3. (Unobscured observations) Check whether the accuracy circle of the observation intersects the bounding box of North America. (Cheap) Go to the next observation if it intersects.
  4. Check if the central point is inside the North America polygon. (Cost scales with how complicated the polygon is.)

So they even avoid computing whether accuracy circles intersect with the polygon to keep the cost down. The most expensive thing done is deciding whether the central point is inside the polygon of the place, and that’s only done for the points which are inside the bounding box.

6 Likes
12

Given these are standard places we are talking about which tend to be pretty large, and the lack of alignment between the maps shown to users and what is used in the calculations, I think I would be happier if this were to be implemented with say a 1km or larger buffer requirement.

Unless the objective is to get people to enter 0 as the buffer which is not really any more accurate, it will drive people who care about their place checklists batty trying to reposition or minimize the buffer.

1 Like
13

Because iNaturalist treats places used for the City Nature Challenge as standard places - otherwise most threatened/endangered species found during the CNC would not be included.

2 Likes
14

Oh right. Thanks. :) Forgot about that since the organizers had changed the CNC place for Chicago in 2020.

3 Likes
15

That makes sense. Thanks very much for the detailed answer.

2 Likes