[kismac] Re: possible GPSd implementation by William

>  >So I'm happy, and promise to finally look at the source code to see
>>what is involved in switching to gpsd, in the hopes that GPS data can
>>be accessed by more than one app at a time.  And I'm going to write
>>some sort of script to take the netstumbler export and turn it into a
>>simulated waypoint file to view in MacGPS Pro.
>
>If MacGPS Pro can access GPSd, and you write code to implement GPSd,
>you COULD think about GPSD reading the netstumbler input rather than
>the GPS device (e.g. if no device is available or by whatever
>criterion) and use that for GPSd output... Or is this a silly thought?

Location via detected access point is not silly; MacGPS Pro is an 
older app, though; I don't have the MacOS X version yet.  As it's 
heritage is Mac OS 8 or so, I doubt it can use gpsd, but, as I say, 
my copy is out of date.

>Will GPSd be a true daemon and (hence?) be faceless, or is it an
>application with a GUI front end, or maybe a preference pane?

My thought was to leave it as a daemon, to retain commonality with 
the original source (I've run it that way from the command line, and 
it worked without any changes to the source), with a application or 
preference pane to set the port/device to listen to, and turn it on 
and off, as you won't always have the GPS receiver attached and may 
want that port back.

Apple gives an example of writing a GUI app that uses the command 
line to control mp3 playing; I thought I'd start with that, and then 
think about proper enhancements (such as remembering the state of the 
daemon across reboots, and autodetection of NMEA streams) later. 
This does make it more "fragile", in that the daemon and the settings 
shell application both have to reside on the drive as separate files, 
each subject to damage or erasure.

I'll also probably dig into the usenet archives to see what past 
discussions have occurred about what I would have thought the normal 
*NIX way of doing this would have been: /dev/gps.  It seems to me 
that, as this doesn't exist, there must have been a flamewar over 
whether or not it should be done at some point in the past.

I doubt I'll get anything visibly done on this for a week, by way of 
warning, and, of course, this won't get plotting done, except through 
third-party applications (I'll have to look at GPSdrive; it was on my 
list, but I wasn't sure how much fiddling it would take to get 
compiling.  Looking in google with keywords of tiger, gps, and linux 
would produce a number of different attempts to replace deLorme 
StreetAtlas in an open source world;  But map data seems to be 
something that companies are loath to let out into the world without 
constraints.  I know of one company, involved in car navigation 
systems, that talked of making their data format a standard, but you 
had to sign a heavy agreement to get the spec document, and it didn't 
come with sample data.  You can buy a yearly subscription to their 
disks, but some of their systems use the data in encrypted form, so 
you have to know which ones are not encrypted...)

Oh, and those of you with GPS running already, using the netstumbler 
log export, am I right in thinking that the longitude and latitude 
figures given:
N 42.006413     W 87.566795     ( 101 ) BSS
are dd.mm(.)mmmm?  Nothing else seemed to make my home location come 
close enough to my normal home waypoint.  So that the above would be:
42.010688  -87.944658
in decimal degrees?

Other related posts: