|
From: | address@hidden |
Subject: | Re: [gpsd-dev] Using multiple location sources to improve a ccuracy and reliability |
Date: | Tue, 10 Jul 2012 10:49:31 +0200 |
Hello,
if you have more then one source of the position, the idea is obvious to merge them into one position, as most of the gpsd aware applications expect only one position source.
For me the point is, that there is already so much code in gpsd that address the needs of only very few people, and this options need difficult configuration, and it may be implemented in so many different ways.
Perhaps it is time to consider a plugin interface to keep gpsd lean, to fulfill special needs, and to avoid multiple coding.
Reinhard
-----Original-Nachricht-----
Von: Eric <address@hidden>
An: Olivier Cornu <address@hidden>
Cc: address@hidden
Betreff: Re: [gpsd-dev] Using multiple location sources to improve accuracy and reliability
Datum: Mon, 09 Jul 2012 16:17:09 +0200
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="">Eric S. Raymond</a>
[Prev in Thread] | Current Thread | [Next in Thread] |