Re: some observations on the design intent of gpsd

[Gary E. Miller]

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 <don.rolph@gmail.com> 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.


RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

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

pgpehWGSDlub7.pgp
Description: OpenPGP digital signature