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

[address@hidden]

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>