Please fill out the following sections to the best of your ability, it will help us investigate bugs if we have this information at the outset. Screenshots are especially helpful, so please provide those if you can.
Platform (Android, iOS, Website):
Website
App version number, if a mobile app issue (shown under Settings or About):
Browser, if a website issue (Firefox, Chrome, etc) :
Version 79.0.3945.88 (Official Build) (64-bit) on Windows 7
Screenshots of what you are seeing (instructions for taking a screenshot on computers and mobile devices: https://www.take-a-screenshot.org/):
Description of problem (please provide a set of steps we can use to replicate the issue, and make as many as you need.):
Step 1:
I submitted an observation via the web site. I happened to select a wrong place on the map.
Step 2:
After submission, I saw the wrong place and edited the observation. I chose the correct place on the map.
Step 3:
The observation shows the correct place on the map, but still shows the incorrect place name (“Giessen” instead of “Hallgarten, 65375 Oestrich-Winkel”).
Yes, it’s not a bug so I’m going to close this. When you make an observation we fetch a name (which we call the “locality note”) from the relevant map service and add it to the observaiton. That locality note is static unless the observer manually changes it, which they can do via the observation’s edit screen on the website or Android app.
Thanks for insight on “locality notes”, I understood how that feature exists now (which I never used before myself and so is the user raising this bug report I feel)
just as recap, what is happening is: when a user picks a coordinate via map picker or via search text or directly as a point tap on map, there is a googlemaps GeocodeService search API request for those place text or coordinates that inturn finds a place guess, and this is inturn saved as a “locality note”. Now when the same user edits these coordinates again, such “locality note” is not touched by inat unless they manually edit that note again.
An user can edit this “Locality notes” (text that google said first) before saving as a way to correct the Google maps guess better (say if that place is not present in google maps in first place and user wants to record it better) and this is the current design case.
But I do feel there is a bug and that problem comes from two different features merged into that one text, aka an user manually creating their own locality note versus an user never creating such locality notes manually in first place - both of these are not decoupled although they should be. The latter is what happened in this bug report (and I am sure many users do the latter too)
Ideally, I think the code should decouple user-generated locality note edits (detectable by final note text different from google maps API place result) or auto-generated API place notes, and in the latter case (as in this bug report) such place-locality-note text should always reflect the latest true API results on future edits always since there is no reason to preserve the locality text - which was never a manual entry - and the system is wrongly assuming these are manual entries and should be preserved as absolute when they have just come from actual pins or text search
The explanation above indeed offers a reasoning as it is implemented in system now but as explained above, and the user bug report, it is a bug that occured as it conflates two things into one data.
here is a clear flowchart again - User C is kind of like this bug report user (and many such users who upload simply without creating manual locality notes), and the reasoning offered above is the case of implementation for User A only as it exists now while User C edits are wrongly handled as of now from wrong assumptions:
@einsum I apologize for re-opening this, I don’t think it’s a bug. I’m pretty sure our decoupling the the updating of coordinates and the updating of existing locality notes was a conscious decision, letting the user be responsible for the content of the locality notes. As to whether that’s the best choice on our part can be debated, but I will be setting those to close again.
