[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some observations on the design intent of gpsd

From: Gary E. Miller
Subject: Re: some observations on the design intent of gpsd
Date: Wed, 5 Jan 2022 12:18:31 -0800

Yo Don!

Can you please use a standard quote style?  If you can't follow
email standards, why would you expect to follow GNSS standards?

On Wed, 5 Jan 2022 14:51:15 -0500
Don Rolph <> wrote:

> Let me clarify on some of your points:

I thought it was clear the first time.

> Your material:
> > Many users, however, are looking for an abstraction layer over
> > location.  
> Care to clarify what is "over" location?  gpsd stops at giving you
> lat/lon/alt.  If you want your street address, then pass that up to
> a map program.  If you want your statistics, pass that to gnuplot,
> etc.
> My response:
> actually based on some ontology work I have done, lat/log/alt with
> possible speed and header are the key information elements.

Yes, of course.  Which is what gpsd gives, many ways.

> However, creating an interface which provides this capability AND
> supports the additional gps data structures seems to add complexity
> to the service.

Which is why gpsd provides many simple ways to get the lat/lon/alt.
Why not use one of them?  The DBus service from gpsd sounds about right.

OTOH, I don't see how a 10 line client for JSON is a big burden.

> At the locatio abstraction layer, strip out all but
> locations and associated data

Why strip it out?  Just ignore it.  If complexity is a problem, then
use the DBus interface.

If a 10 line client is too hard, give up now.

> and have a stable interface across
> changes in the satellite data,

gpsd has that.  The lat/lon/alt  int the TPV part has been pretty
stable for what?  15 years?  Compare that to openssl, ffmpeg, http, etc.

> > While gpsd provides a location abstraction layer with the TPV
> > message, the additional complexity of providing an abstraction layer
> > over most gps receivers complicates the use of gpsd as an
> > abstraction layer over location.  
> Uh, lost me.  That seems circular.  I look at it this way: you
> start gpsd, you get lat/lon/alt out.  What more, or less, do you
> want?"
> I reply:
> an interface whose only message is position.

Sounds like the DBus interface.  Or the JSON interface when you just ignore
the stuff you don't want.  Ignroing data costs nothing.

> That way when satellite
> data changes, it does not impact this interface.

Uh, lost me again.  What changed?

> Creating a call
> which can be restricted to TPV messages but must also maintain
> support for other changing messages, appears to be adding complexity
> to the user calls.

Good, then we will not do that.  Why bring up ideas you do not like?

> "> You can actually see the Dire Wolf author's design includes this
> > wrapper approach, although it is nascent at the  moment.  
> Please, don't bring up the broken Dire Wolf code as an example of
> anything but laziness.."
> I reply:

Once again, don't care.

Yes, please do not do so.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpehWGSDlub7.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]