> >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?