Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Location: Improve Riparius handling #2300

Merged
merged 3 commits into from
Aug 10, 2024
Merged

Location: Improve Riparius handling #2300

merged 3 commits into from
Aug 10, 2024

Conversation

nimmolo
Copy link
Contributor

@nimmolo nimmolo commented Aug 9, 2024

This should make the autocompleter less eager to override a manually entered place name when there is also a lat/lng from a photo.

It will still however retrieve Google's version of the place name formatted for MO, so for example "Riparius, New York" becomes "Riparius, Chester, Warren Co., New York, USA".

It also hopefully fixes a JS error where the bounding box hidden fields stopped being updated by the user manually resizing the box.

@coveralls
Copy link
Collaborator

coveralls commented Aug 9, 2024

Coverage Status

coverage: 93.52%. remained the same
when pulling 9ade58e on recent-stimulus-changes
into f34c17c on main.

@nimmolo nimmolo marked this pull request as ready for review August 9, 2024 23:27
@nimmolo nimmolo requested a review from mo-nathan August 10, 2024 09:15
@nimmolo
Copy link
Contributor Author

nimmolo commented Aug 10, 2024

@mo-nathan I thiiiink this smooths out most of the weirdness. If you have time, and are able to return your local db to a Riparius-agnostic state, check it out and let me know how it goes.

It shouldn't keep overriding the place with "Chester" when you delete the place name and try to type "Riparius..". It should just offer you a "Create locality" button, and when you click that, it should fill it with Google's version of the place. You can then edit the borders.

There may be other issues but i think this is at least an improvement. There are so many interdependent factors and ux triggers.

It occurred to me i might as well state them, it may help us in the future.

  • any change to the lat/lng fields (via image upload or manual entry) that results in a valid lat/lng pair should trigger an immediate (buffered) query for MO Locations containing the point. Behind the scenes, the autocompleter changes mode from "text matching" to "location containing point".

  • If that query comes up dry, the autocompleter changes mode once again to "location google". It sends the lat/lng to google to get names for the localities containing the point. This is strict: note that G's bounding box for Riparius is tiny, so this observation lies in Chester Twp according to G.

  • When you have lat/lng, the autocompleter will only offer matching localities for the point. But if you delete the place name and start typing, it should offer the "create" link.

  • If you hit that link, the autocompleter goes back to "text matching" mode - but for Google localities, not MO locations. G only returns its single best match, unless you use paid credits. It seems to do OK, and it does return a bounding box that you can then edit.

  • Note that the "Clear location" button clears both the lat/lng, the place name and the box.

@nimmolo nimmolo merged commit 71a6e4a into main Aug 10, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants