A note about compass data

[mikebolt]

I spent some time working on collecting geospatial data for a mobile driving application. Like GPS data, a mobile device's compass data can be inaccurate for a number of reasons.

Here's an open question:

Should an implementation of this specification use algorithms to correct or make useful the compass data?

If the answer is yes, then there will be tradeoffs between the accuracy and consistency of the data. If the goal is a smooth 60+Hz signal (which would be great), then some kind of processing is necessary, so that objects aligned somehow with the compass vector don't move around erratically.

There are some ways to calibrate the compass with other sensors, including the GPS sensor, but because the GPS sensor is error-prone for other reasons this can be difficult. Local calibration (that doesn't care about north) can be done without the GPS data, by requiring the user to move the phone around during a calibration process. It may be possible to get an accurate north vector by isolating the "static" component of the compass vector. The idea is that as the device moves around within a space, the geomagnetic component of the compass vector is constant, whereas interfering sources of magnetism may vary.

So here's another open question:

Should this specification deal with compass calibration?

Also, make sure not to confuse magnetic north and true north :)

[mikebolt]

The latest Android OS handles isolating the geomagnetic component (link), and likewise for iOS (link).

[blairmacintyre]

Interesting; I was envisioning that much of this would be handled already by the OS. ARKit does everything this proposal requests (you can ask for the ARKit coordinate system to be aligned with EUS).

For Android, or other platforms, things might be more complicated (e.g., Hololens and the ML1 doen't even have compasses, but it's conceivable that some day their "spaces" could be aligned with EUS using other means, thus giving this ability another way).