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

improve detection of current location, for accurate distances #46

Open
jeffkowalski opened this issue Jul 15, 2024 · 1 comment
Open

Comments

@jeffkowalski
Copy link
Collaborator

The present implementation does not yield accurate operating location, leading to very skewed distance calculations.

While on Pine Mountain, https://sotl.as/summits/W6/NC-331 in Northern CA, on 2024-07-09, ip-api.com returned that I was at (36.102, -115.1447), which is in Paradise, NV, just South of Las Vegas.

We use ip-api.com in the current code to get the apparent location of the operator. This does not use the GPS on the phone. Regrettably the very straightforward use of navigator.geolocation.getCurrentPosition is available only under HTTPS, so we have to use a service that attempts to locate the operator by IP, presumably by cell-location. But we're getting a bad result.

Choices are:

  1. Enter the location manually, perhaps the current park/summit code, and look that up
  2. Find a better service than http://ip-api.com/json/?fields=status,message,lat,lon that offers greater accuracy
  3. Implement HTTPS so we can use the GPS-based location. Coding this is simple. There is a minor performance hit for encryption/decryption. The greatest challenge is determining what to do about certificate generation and distribution.
@brianmathews
Copy link
Member

...and Jeff also suggested option #4:
4. Have SOTACAT make a "deep link" call to SOTAMAT app and ask SOTAMAT for the GPS location. SOTAMAT would then return to the URL provided to it by SOTACAT with extra URL parameters for the current Lat/Lon. There is a security/privacy concern with this and SOTAMAT won't be able to trust the origin of the inbound deep-link. One solution is to ask the user to confirm they want to share GPS location with a web page.

...and Brian has a similar idea #5:
5. Since we only need geolocation when we have internet (for the click-to-pounce distance table), we could have the JavaScript make build a 1-pixel <iframe> and that <iframe> could make a call to the https://sotamat.com web server using HTTPS, receive JavaScript via HTTPS from that server, get the GPS coordinates using the HTTPS based page, and then have the <iframe> javascript communicate with the parent page (HTTP) Javascript using the PostMessage API.

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

No branches or pull requests

2 participants