nickw1
commented
3 years ago @gitToad so do we still need to compensate for declination? i.e. are the inbuilt corrections with the APIs good enough?
If not there is a third-party library to do this, which we could use: https://github.com/naturalatlas/geomagnetism.
What is the current behavior?
I believe the current heading from rotation-reader used by the gps-camera and gps-projected-camera is based on the magnetic compass in the phone. Shouldn't there be a compensation for magnetic declination ? Ie. any objects in the scene specified by lat/long will be rotated in y by the amount of magnetic declination (resulting in what looks like "wrong" registration of the AR overlay and the real world.) https://geomag.bgs.ac.uk/education/smartphones.html
If the current behavior is a bug, please provide the steps to reproduce.
Easier to test in areas where magnetic declination is significant. Here in California ~15 degrees, quite noticeable. UK ~2 degrees, Brazil ~20degrees !
Please mention other relevant information such as the browser version, Operating System and Device Name
using these (slightly older) versions because latest ones have other bugs that prevent use in my app:
I believe the current behavior is a bug. The fix might be to add a parameter to the gps-camera that allowed entering the magnetic declination for the current camera location. Since this doesnt change very much, you wont need to update it often/ever unless you travel very large distances.
What is the expected behavior?
Using gps-camera or gps-projected camera and rotate-reader, I would expect a-entities with precisely entered lat/longs to show up over the real world locations of those objects, not rotationally offset.
If this is a feature request, what is motivation or use case for changing the behavior?
both a bug and a feature request (to fix the bug) motivation is that current behavior results in systematically wrong/offset AR objects.
--- edit after a few days of pondering / researching this --- It looks like the web APIs (Android: DeviceOrientationEvent alpha and iOS: event.webkitCompassHeading) already provide true North rather than magnetic North. Ie. they know your location from Wifi or GPS (roughly is good enough), look up magnetic declination for that area from some table or website, and automatically subtract that from the magnetic compass heading to provide true North headings. In which case there is nothing in AR.js to compensate for any more. On iOS, you can (should?) enable Location Services for the compass and in the compass settings, and make sure that "True North" is enabled (source). I assume those same settings are also applied to what heading our web apps get from the system.