I understand some users usually pick locations via search, and some locations with same or similar names can end up elsewhere if there is matching geographic location with different coordinates sometimes and more so if users initial place search and selection happened to be inadequate to catch these address twins.
But now look at this observation, google maps somehow already identified this place is ecuador, as the original observer and their intention and the observation location should all be, but then the coordinates saved with corresponding accuracy ended up in Indian ocean somehow, I cant even guess how it could have even happened but it did here.
ok the latitude is correct, and the longitude instead of being around -78.475 ended up getting saved as 91 hmm. maybe there is a bug in pipeline that inat should check asap to prevent more such corruptions.
it looks like the observer has corrected these at this point.
there were multiple observations from the same location that were uploaded over several days, and the longitude value was 91.0 exactly. so i’m guessing the observer accidentally modified the longitude on a pinned location and then used it for that set of observations.
alternatively, they could have batch edited this set of observations and instead of editing, say, accuracy, they edited longitude.
or they could have accidentally included this set of observations while batch editing observations to that particular longitude.
probably only the observer will know what they did. it’s unlikely a system issue.
When I was first uploading sightings from this location I was using GPS coordinates, but then found the name of the lodge in a drop down so I used that instead. For some reason, longitude ended up being 91.0 instead of -78.475491 for several observations. I went back and used batch edit to search for and correct these entries.
to me that actually sounds some failure case in system code rather than user specific gymnastics as it looks normal flow?
Right so it sounds like the observations were uploaded with a location in Ecuador and then changed, but the place guess didn’t change. This often happens if something is off with the metadata and it’s at the upload location instead of the observation location.
not sure why you think would take gymnastics to create this sort of situation. one user input error is all it takes in any of the 3 scenarios i noted.
what we know is that the locations are user-input (as opposed to one determined by a GPS-enabled device). those sorts of locations are the ones that are going to be most likely to pick up user entry errors.
that said, i’m not sure this is worth spending much more time on. the user has already corrected the observations. if you think there’s some sort of error in the code, you can try scanning through the code to find that needle in a haystack or you can spend time trying to figure out a way reproduce it. (i doubt any iNat developer would spend any time on this without that sort of information.) short of that, it’s probably time to move on.
But what exactly is the user input error here? do you think such longitude edits should never change place guesses in turn too on open observations?
what my wild guess is, there is a true location coordinates → that is place guessed by google maps api correctly as Ecuador as their lodge they picked → the true coordinates ended up getting saved as wrongly by code for some obscure edge case here and ended up in Indian ocean.
Do you have other plausible explanation otherwise for this scenario of “coordinates point in Indian ocean” and place guess in “Ecuador”?
but if its a true bug, its not anymore about the point of whether that single user corrected things. anyway I will check code later.
i don’t really understand what you’re hung up on. the place guess doesn’t necessarily change if you change the longitude. try it.
that’s not necessarily a system bug either. it’s just a design choice. not everyone wants to accept whatever the Google Maps reverse geocoder decides is the location for a particular coordinate. so the system doesn’t always attempt to get that if a coordinate changes.
but, this argument of correct design choice is actually relevant only if the user corrected a google maps geocoder in first place right?
aka “not everyone wants to accept whatever the Google Maps reverse geocoder decides” so only if they wrote manual locality note and then the system should not touch it on new edits and let the user be responsible. we all agree here.
but under the equal argument if the user is never correcting such automated api results during first upload (say they picked coordinates or gps autopicked coordinates) and then gmaps auto assigned a place text as auto-generated locality note and they havent touched this.
under this condition, the next edits on observation coordinates should also make such geocoder system responsible for correcting this previous “auto generated” locality note it wrote right? it looks somehow wrong to suddenly make user feel responsible for correcting the mistake that geocoder did earlier on that text (the user never wrote that text), by refusing to listen to how user’s coordinate edits should effect the previous such autogenerated notes?
it was new to me because I only upload via inaturalist android mobile app and such text there autochanges in this exact logic I am talking of above aka when I pick coordinates and then later pick new coordinates on map on edits. and then the gmaps autocorrects its earlier “autogenerated place text” mistakes as I am trying to ask above.
I don’t use the apps enough and can’t comment on that, but will just add that ideally the behavior should be the same between web and app platforms (i.e., if editing triggers a location text change on one, it should do that on all or have all not do that).
