anytime someone plugs in an access point, they're setting up a geo-location beacon. computers can detect the access points in the area and that gives a good idea of where it is in the world. even better, an access point does not have to be 'associated' to the laptop and encrypted APs still work for geo-location purposes. the MAC address is always there unless 'beacon' packets are turned off.

wigle, skyhook, and plazes all know this and have mac address databases. none of them are creative commons licenced. so we need to start again and build a database of access points that is more freely redistributable. i thought about a new service but then it dawned on me that tracking access points is exactly like tracking people. they dont move as much but really its just another object for icecondor to track. to support the tracking of access points in icecondor, a place for the mac address, which is its guid, must be made. i'm thinking of making up some URN like wifi:00:11:22:33:aa:bb and using that in the guid field in icecondor. alternatively, an icecondor record may need to support a freeform hash to store extra attributes but i'll put it off for now.

i think laptops may be the first and best angle for icecondor clients and continuous location reporting. AP beacons are everywhere and every laptop has wifi. in linux i'd like to see a module for gnome's NetworkManager application that does a best-effort stay-in-the-background dont-get-in-my-way approach to doing HTTP posts at a configurable interval to an icecondor service provider. for OS X the parameters of the daemon will be configured in a userspace app. on first launch it will setup the launchd hook for the daemon. the whole field of access points in range instead of the connected AP (if any) will provide the best location information. i guess its similar to tracking a larger number of GPS satellites. wifi drivers and operating systems are very different on how much of such data is available.

what does it mean to be 'in range' of an AP? even lat/long reporting is rather ridiculous because we never know exactly where anything is. its a probability field. a range with an error estimate. if a client posts "i'm near AP 1:2:3:4:5:6" and its the first time that AP has been reported, its lat/long/alt will be undefined, so the client's lat/long/alt will be undefined. through the web interface, unknown APs can be located by hand. then on the next location report, the client's lat/long/alt will be in a circle based on the AP's lat/long/alt with an error estimate of a standard 'reach' for an AP - probably 300 meters. Or for a group of APs in range, the geo-location average of all their lat/long/alt, weighted by signal strength if thats available.

the icecondor API needs to be extended. location can be reported by lat/long/alt, or it can be reported by referencing an icecondor guid/uri. in the AP case, the http POST would be something like guid=<my id>&next_to=<other id>. now your location can be relative to an AP or another person. perhaps bluetooth discovery sees a friendly bluetooth MAC and reports the uri of bluetooth:6:5:4:3:2:1. Noone is going to hand-place the lat/long/alt of a bluetooth device since they move so frequently. maybe inferences can be made if a chain of next-to associations leads to a fixed location.

update: the API has been extended to include 'next_to', and expands on the URN usage.