[kismac] Re: possible GPSd implementation by William
- From: "William H. Leininger" <whlm1@xxxxxxxxxxxxxxxxxx>
- To: kismac@xxxxxxxxxxxxx
- Date: Sun, 11 May 2003 12:57:13 -0500
> >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:
