Let me clarify on some of your points:
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.
However, creating an interface which provides this capability AND supports the additional gps data structures seems to add complexity to the service. At the locatio abstraction layer, strip out all but locations and associated data and have a stable interface across changes in the satellite data,
You stated:
> 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. That way when satellite data changes, it does not impact this interface. 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.
You stated:
"> 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:
it probably behooves one to look at the issues encountered rather than make claims about the authors. If you have specific improvements to the gpsd code, in Dire Wolf that makes sense. But I suggest that every coding effort is idiosyncratic based on the intent of the coder. And I have long since concluded that arguing style, rather than function, is useless.
Right. now I have shown that code which works correctly under gpsd 3.17 is giving incorrect responses under 3.22-400 or 3.23.2. Ths issues are:
- can we identify the nature of the problem?
- what does a fix look like?
And pretty much editorialization outside of these points is probably not constructive.
You stated:
"> These are my impressions from the effort. Your mileage can and will
> vary.
Yeah, they do."
But if I might, I don't think I understood your position regarding a pure location service layer. Can you expand?