Curiously variable inferred location

Bug Reports
1

Platform website:
Browser Chrome:

I uploaded many observations, most composed of several photos, made at Sarykum Sand Hill in Kumtorkalinskiy District/Rayon, Dagestan, Russia. Each time the first photo got ‘Buynakskiy Rayon’ in the inferred location while all other photos ‘Kumtorkalinskiy District’. Each time the photos were just different shots made while I did not move, and project to the same correct point on the map. Buynakskiy District is nearby, and I know very well that borders are approximate here and administrative attribution may vary and be somewhat incorrect. But I am amaised by the strict regularity in this area: the first photo always wrong, others correct. Examples:

image
image1366×768 187 KB

image
image1366×768 239 KB

2

it doesn’t look like you’ve actually loaded these observations yet. what are the exact coordinates of those photos (both good and bad)?

my first thought is that even though they look like they’re the same point on the map, their coordinates might be ever so slightly different. however…

i’ve never looked deeply into this, but i suspect the automatic place descriptions are usually determined by the boundaries established by Google (via reverse geocoding), but it’s possible that in some cases, the automatic place descriptions come from iNat places.

i’ve previously noted behavior where some observations get a detailed place description (as if reverse geocoded), and others simply get a county-equivalent place description: https://forum.inaturalist.org/t/rename-loading-metadata/2826/7. i never understood exactly what was going on here, but i think it still happens, and it may be what you’re seeing in your case.

3 Likes
3

Since I could not illustrate the case with already uploaded observatoins, I made these examples without pressing ‘submit’ but sumbitted those photos in about half an hour. The coordinates varied in some 6 digit after the comma, as usual, and differently for different photo sets, nevertheless each time the first photo had B… District and others K… District. I suspect that outlines of both district were rather rough and just overlapped in that area. I noticed that the B has the Russian word ‘rayon’ (which means district) and the K has the English word ‘district’. It looks like these two belong to different series of places, as you supposed, and iNat has different priority irder of place search for the first (main) and subsequent photos. Of course, there is no big problem in this at all.

4

This strange ‘rule’ continues: the first photo in a series uploaded gets a different district for location than others. A very remote region (central Siberia) from the previous examples (the Caucasus) but the same problem. Here ‘rayon’ means ‘district’ in Russian. Tandinskiy Rayon is correct, Kyzylskiy Rayon is situated northerly.

image
image1366×768 198 KB

1 Like
5

iNat gets the the “locality note” from Google Maps (or Apple Maps in the iOS app) - it just sends the coordinates to the map service and displays whatever name is returned by the map service.

Can you please send a group of these photos to help@inaturaliast.org so I can test them out? Let me know which photo was listed first here.

6

there must be an alternate path in the code though, since based on the examples in this thread and what i’ve seen myself in the past, the upload does seem to sometimes (randomly?) determine location based on iNat places. for example, if the reverse geocoding service fails to respond or if there’s some sort of race condition, then maybe the fallback is to get a location based on iNat standard place boundaries?

2 Likes
7

I don’t have GPS so I set my location manually. I ask for a pinned location, then move the pin to where I saw that plant. As I move it, the named location changes. Then I edit back to what I want it to show.

Might be good for uploading to encourage observers to check that the displayed location is what they want and meant. Silvermine Reserve always displays as 2 words - Silver Mine - which is nonsense. It was originally named for a mine, which disappointingly didn’t have, any silver. The mine is history but ‘Silvermine’ (as one word) remains. (Which is the map service’s error, not iNat’s use of it)

Obs on Elsies Peak in Fish Hoek display as Farm 964, Cape Town … which is meaningless to most people. Fish Hoek would be meaningful - but it is up to the observer to know that they have to edit it to make sense.

8

Platform - Website

Browser, if a website issue - Chrome:

The bug similar to already discussed in the forum, but very specific and persisting for at least to years.
I post photos geotagged in EXIF, they are all mapped correctly. The locality notes are populated automatically. But if I post a series of subsequent photos taken in, say, seconds one from another, the loclality notes very often show different districts, a correct one and a neighbouring one, the border of which is,. however, quite far. Here is an example:

image
image1366×768 184 KB

Here Shushenskiy District is correct while Ermakovsky District is wrong, and its border is maybe 40 km apart.

You may see that all photos map to almost the same point (that is correct, since they were taken while I did not move):

image
image1366×768 103 KB

Yet the districts are different! Most frequently, it is the first photo where automatic locality notes are wrong and but correct in the rest.

Now I try to post the first photo alone:

image
image1366×768 134 KB

Viola, the Shushenskiy District is correct.

Up to my experience, if a single photo is uploaded the district in notes is always correct, but too often it is variable in a simultaneously taken photo series.

Another try of another series:

image
image1366×768 186 KB

Again, the same two districts, incorrect in the first photo, correct in two others (the most common situation).

This bug is persistent for not less than two years, and appeared in photos from very different regions - the district populated was usually wrong in the first photo regardless how far that district it is from the actual locality.

This is very annoying. Although I always replace atomatic notes with my own, the automatic notes are retained in ‘encompassing places’, which provide misleading information. In my file naming system, the best photo goes first and when it becomes the front photo of an observation it results in mislerading encompassing places.

Could it be made so that the automatically populated locality notes be correct even in each (especially first) photos in series automatically uploaded?

1 Like
9

I don’t think this is a iNaturalist bug, i would rather think this is a google maps bug. I have seen several dozend iNat observations near the Haitian / Dominican border with GPS point on side and the country assigned on the other side of the border.
Provinces, Departments are often wrong too, but as long as the GPS points are in the right place, i don’t really care.

10

My further observations suggest that the longer time metadata reading / automatic locating of a photo from exif data takes, the more correct its administrative attribution is. When I upload a series, the metadata are read from first 1-2 photos very soon, often immediately, while it takes more time for the rest. And the former became attributed to a wrong district while the latter correctly. If I then open the map window of a qrongly attributed photo and shift its map position with a mous even fgor 1-2 pixels, the attribution immediately becomes correct. So it is a matter of interaction of iNaturalist with Google Maps. It seems that it starts with a very rough locating as to administrative subdivision which is made more precise with time, but the locating process may finish earlier. Maybe some retardation of populating the locality note windiw would solve the problem. Anyway, map location of a photo itself is always correct and the problem is only with automatic administrative attribution.

11

this thread is probably just a continuation of https://forum.inaturalist.org/t/curiously-variable-inferred-location/34937 and should probably be merged with that one.

you’re describing something that is probably the net effect of 2 different quirks in the system:

  • the boundaries of the administrative places in iNat come from GADM and are sometimes inaccurate or imprecise. so to the extent that you see bad encompassing places after upload and occasional bad location descriptions during upload, it’s related to bad (imperfect?) boundaries loaded in the system.
  • there seem to be two possible paths for loading metadata in the web upload page. one will load based on Google reverse geocoding, and the other is based in the administrative boundaries loaded in iNat. i’ve never looked deeply into why this happens exactly, but this is my description of that: https://forum.inaturalist.org/t/rename-loading-metadata/2826/7.

for what it’s worth, i don’t know if these would be considered bugs. the boundaries loaded in the system were probably just the best available information at the time, and the alternate path for location description lookup might be a fallback for when reverse geocoding via Google fails.

12

I agree this is likely not a bug, but if you can share those three photos with help@inaturalist.org via Google Drive, Dropbox, or something similar, I’d be interetsed in testing this with them.

Locality notes are not linked to ecompassing places. Encompassing places are listed by iNat and they’re based on the coordinates and accuracy radius of the observation, not the locality notes.

1 Like
13

i don’t think you need a particular image file to reproduce the second quirk that i described in the previous post. the quirk seems to occur when a call to the Google geocoding service fails for some reason. so to reliably reproduce the quirk, you’d probably have to block the request to the geocoding service, like so:

  1. go to the web upload screen
  2. open your network monitor in your dev tools
  3. upload any image file that has coordinates. notice that its location notes will be based on whatever description is returned from the geocoding service.
  4. find the call to the geocoding service, and block that domain:
    image
    image1491×974 108 KB
  5. upload the same (or another) image file that has coordinates, and notice that when it’s done, its location notes will be based on the county-equivalent iNaturalist standard place:
    image
    image1489×1039 172 KB
  6. (just to restore things back to normal) unblock the geocoding service dormain
1 Like
14

Thanks. FWIW I didn’t get a county-level place but a local park, but the two were definitely different:

image
image1164×874 90 KB

Coordinates are 37.7352049167, -122.2097692222

15

hmmm… i assumed it was a county-equivalent place, since that’s what i’ve always gotten. California has town-level standard places though. i wonder if that makes a difference? (maybe it is looking for the lowest-level standard place to be a county-level place, but when it’s not, then it falls back on the first community-created place or something like that? i guess it doesn’t really matter exactly what it’s doing, but it just seems more logical to fall back to a standard place when there is one rather than a community-created place.)

1 Like
16

Probably, this is a park that was added a looooong time ago https://www.inaturalist.org/places/martin-luther-king-jr-regional-shoreline.json

17

Your obs with the map shows ‘no accuracy recorded’
That could explain different results.

18

lack of an accuracy value has nothing to do with this.

it might be time to close this bug report, unless iNat staff actually plan to change standard place boundaries or change the way their reverse geocoding process works.