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: Frank Nicholas
Subject: Re: some observations on the design intent of gpsd
Date: Wed, 5 Jan 2022 13:37:09 -0500

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


reply via email to

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