gpsd-users
[Top][All Lists]
Advanced

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

Re: some observations on the design intent of gpsd


From: Don Rolph
Subject: Re: some observations on the design intent of gpsd
Date: Wed, 5 Jan 2022 14:01:19 -0500

Your basic statement is consistent with my thoughts.  further location services could, in principle, use other sources besides 
positioning satellites.

i can state that in my community the primary use of gpsd is to provide location (possibly with speed and heading).

For more precision on usage  we would need a census of gpad users,

Thanks for your comment!

On Wed, Jan 5, 2022 at 1:37 PM Frank Nicholas <frank@nicholasfamilycentral.com> wrote:
GPSD is not intended to be a “location services” (as per the description you quote).  It can include much more information than just location (time, direction, speed, quality of data, etc.), depending on the devices being managed by GPSD, and how they are configured.

A “Location services” tool/daemon could be designed/built to use GPSD as it’s provider/backend.

You might find that GPSD is used as much or more for time synchronization vs. location...

Thanks,
Frank

On Jan 5, 2022, at 12:26 PM, Don Rolph <don.rolph@gmail.com> wrote:

As part of the discussion during my efforts with gpsd, I am sensing what seems to be an interesting disconnect between the gpsd design intent and the usage to which gpsd is often used.

Per the GPSD web page:


the intent of gpsd is to:

"gpsd is a service daemon that monitors one or more GPSes or AIS receivers attached to a host computer through serial or USB ports, making all data on the location/course/velocity of the sensors available to be queried on TCP port 2947 of the host computer. ...  Also, gpsd responds to queries with a format that is substantially easier to parse than the NMEA 0183 emitted by most GPSes."

So gpsd is providing an abstraction layer over the gps (or AIS) receivers.  This is a critical and laudable goal.

Many users, however, are looking for an abstraction layer over location.  In large measure, how location is determined is immaterial, they are simply looking for an abstraction layer over location (and possibly some supporting data).  An example is perhaps the location services in IOS.

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.

It feels like perhaps an additional wrapper is needed to simplify (and arguably stabilize) the interface to location data without limiting the enhancements required by gpsd to accommodate changes in technology in the satellite location functionality

You can actually see the Dire Wolf author's design includes this wrapper approach, although it is nascent at the  moment.

These are my impressions from the effort.  Your mileage can and will vary.

Thanks for everyone's assistance!

--

73,
AB1PH
Don Rolph



--

73,
AB1PH
Don Rolph

reply via email to

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