Re: [gpsd-dev] Using multiple location sources to improve accuracy and reliability

[Eric]

Olivier Cornu <address@hidden>:
> What did i expect? Put simply: more than basic multiplexing.
> I expected to gain something from device redundancy: either improved
> accuracy (reduced statistical error using several measures) or improved
> reliability (if one device starts behaving incorrectly), or both. It seems
> i get none.

That is correct.  The design philosophy of GPSD is that is intended to
pass through clean data identified by device.  The only postprocessing
we do is to compute velocities and error bars from the skyview
covariance matrix if the device doesn't report them.

This is a "mechanism, not policy" design.  You want to add a policy 
layer preferring a particular policy - merge and average.  Or maybe
merge and average after deciding to ignore a device that is "behaving
incorrectly". But what criterion are we to use to decide "incorrectly"?
That's another kind of policy.

There are several reasons not to go this route.  One is the very fact
that GPSD is designed to be a device multiplexer for multiple
applications - we can't know in advance that all applications using
the daemon at any given time will want the same policy.

Another is...if we add one policy, we'll immediately come under pressure
to add policy switches to enable lots of others. The code would bloat,
and there would be lots of new places for bugs to lurk.

Here is what I think you should do.  Pick a scripting language with
JSON support.  Write a proxy daemon that launches GPSD reporting to
a private port, reads the JSON from that, does whatever averaging
or other policy you want, and ships results to port 2947 as if it
were GPSD.  

I might be interested in carrying such a daemon in the distribution.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>