iNat Location

[JoeCohen]

Covert iNat Location to MO Location when importing iNat observations iNat observations have a location (lat/lng point) and positional accuracy (in meters). Convert this to the MO Location that is the MBR (Minimum Bounding Rectangle) of the iNat Location +/- public_positional_accuracy.

Tasks

• [x] new Location scope contains see https://github.com/MushroomObserver/mushroom-observer/issues/1955#issuecomment-2197751209
• [x] InatObs#location for public locations (smallest existing bounding MO Location)
• [x] Controller test
• [x] Manual test
• [ ] #2222
• [ ] InatObs#location for private locations
• [ ] Consider creating a new MO Location if
  • [ ] smallest existing bounding MO Location is too large (vague)
  • [ ] the iNat location adjusted for accuracy smaller than the smallest existing bounding MO Location

[JoeCohen]

Get list of locations containing lat/lng + public accuracy Create a box. Maybe mappable box methods will help, as I need to add meters to lat, lng n = max (lat + public accuracy, 90), s = max (lat - public accuracy, 90), e/w get tricky because public accuracy can push box to other side of 180. Maybe first mbr_area = infinity mbr = nil each loc loc area = calculate are next unless loc_area < mbr_area

mbr = loc mbr_area = loc_area end

Perhaps I can partly piggy-back on app/classes/mappable/box.rb, app/classes/mappable/box_methods.rb

[JoeCohen]

Andrew Nimmo The BoxMethods class computes area, and the AutoComplete::ForLocationContaining class sorts by this method. You could use that as an example.

https://mushroomobserver.slack.com/archives/C040TH9FV/p1720559425916179

[nimmolo]

If the iNat obs contains only a GPS point and it doesn't match an existing MO Location, we probably do not need to create an MO location. (What good would an automatic fudged-area Location be, anyway? It's like a less precise way of describing an obs point; it seems no one else would choose to use such a Location, I'm thinking.)

Also, Observations do not require Locations. They should show up on occurrence maps without a Location association, although that is temporarily not the case.

Suggestions -

• Convert the lat/lng point to the obs lat/lng, and forget fudging the point to an MBR. Some iNat obs presumably have non-point Locations, and these are the ones we should be importing (according to this suggestion)
• Use the contains scope to match the iNat observation lat/lng to an existing MO Location, or maybe create a new MO Location by polling Google, as the form does (shortly). But the latter is a lot of Location-creating, and I don't feel like it's valuable.

[JoeCohen]

@nimmolo: Thanks for the suggestion. I'll give it some thought. I agree that polling Google is generally not worth the effort; it might be worth it if the bounding boxes would otherwise be too large. Some issues:

• Some people like to search MO Observations by Region, or just by plugging in part of the Location name in the pattern search. So IMO, MO Observations should have Locations.
• iNat observations have more than a point. They have:
  • a point :location=>"31.8813,-109.244"
  • a precision in meters :positional_accuracy=>20
  • a public precision in meters :public_positional_accuracy=>20 This can be different from positional_accuracy if the user has obscured (or maybe hidden) lat/lng, or when iNat obscures/hides the lat/lng for the taxon. (iNat obscures/hides lat/lng for some rare taxa. I guess if they're endangered/threatened or something.) public_positional_accuracy can be large -- many kilometers. I haven't looked at the iNat code to determine whether it's always 20m if the location is public, or whether iNat gets that some other way. (Does the EXIF header have a field like that?)
  • a list of iNat encompassing places. :place_ids=>[1, 40, 1253, 9853, 53196, ....] The list includes "standard" and user-curated ids. Standard ids are things like continent, country, state. User curated are random, can be a park, an ecozone, or anything. Easiest to understand by looking at an iNat Obs, and clicking on Details in the map area. Try https://www.inaturalist.org/observations/202555552. The list does not include geolocation of each place.
  • a place `:place_guess=>"Cochise Co., Arizona, USA" Note that places are bounded by polygons, rather than mere rectangles. Also note that sometimes the place name corresponds to an MO Location name, for instance a county.

Can you clarify: "Some iNat obs presumably have non-point Locations, and these are the ones we should be importing (according to this suggestion)"? (We need to import whichever iNat observations that MO users want to import. And, IMO, each imported obs needs to have an MO Location. We don't need to import the iNat place. (And doing so would be complex, as the places can have complex polygonal boundaries.)

[nimmolo]

Interesting.

Sounds like we should be taking the smallest encompassing iNat "Place" and getting the name and bounding box of that. (Any geometry column should also have the MBR available in the data list, it's part of the spec.) We could ignore the other geometry of the place. The place is the one that's likely to have a meaningful, searchable Name (like a county or park, or whatever), and this name may even correspond to an MO Location.

The most attractive option to me, since in my mind we are moving towards using geometry columns for Locations in the near future, would be to import the iNat Place geometry into MO without necessarily using it yet. If we move to the geometry data type for obs and locations, observations will no longer need an associated Location, only a lat/lng. The user could search for a Location like "Cochise Co., Arizona, USA" and the database query could pretty easily compute all observations whose GPS point, or associated Location bounding box, lies within that geometry. (The geometry can be a bounding box or a rectangle, it doesn't matter. It can also start as a bounding box and be later converted to a polygon.) That would be a significant improvement for MO, where the obs must currently be explicitly associated with Cochise Co., not one of the towns within it, to show up in such a search. This is how iNat is doing it, i would imagine.

To arrive at an algorithm for selecting among the iNat Places may seem tricky, but i would guess the "standard" types are probably the Google types that i'm picking through with the Google place matching. (If there's anything called administrative_level_3 etc, then these are most likely Google's map place categories.)

I don't think we have a use for the "accuracy" stuff yet, although it would be good if we did. I still feel like an MBR produced from their accuracy radius is little better than fudging points, it doesn't really add to the accuracy or searchability.

[JoeCohen]

• geometry would be cool. But I'll file it for future reference. I don't want to delay iNat imports.
• For importing iNat observations, I start by importing the observation data. That data has a list of bare place_ids, no other info about the places. Looks like this: "place_ids":[1,20,1976,9853,51894,59613,59649,59954 ...]. So I'd have to make another query to get place details.
  • The place details include a single bounding box, which is a polygon. They do not include a minimum bounding rectangle.
  • The place details include a bbox_area, like this "bbox_area": 0.0000192242584172317. I assume this is the area of the bounding polygon, not the area of a bounding rectangle. (The units appear to be thousands of square km's. I haven't checked the documentation.
• I think we do need the accuracy stuff because we need to fudge some points, because some of the observations we are importing have obscured or hidden lat/lng. And MO should make them publicly at least obscure as they were in iNat.
• Other. I just found out that iNat has both public and private lat/lng and positional_accuracy. More documentation here. I don't know if we can get access to the private stuff.

[nimmolo]

There is a way to get an MBR from the Place polygon, even if that polygon is not a box (i.e. rectangle). There's both a db-native way, and mathematical-function way.

(I'm still feeling like one of iNat's Places is likely the most relevant "Location" we'd want to save for our users, because it's likely to conform to the kind of string a user would enter, as a generally-recognized name of an area.)