You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Enter the location manually, perhaps the current park/summit code, and look that up
Find a better service than http://ip-api.com/json/?fields=status,message,lat,lon that offers greater accuracy
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.
The text was updated successfully, but these errors were encountered:
...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.
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:
http://ip-api.com/json/?fields=status,message,lat,lon
that offers greater accuracyThe text was updated successfully, but these errors were encountered: