PerryGeo

A few months back I posted a link to my ten favorite Web Mapping Services. The post included live links directly to the WMS servers. At first I questioned this move as locally hosted images would be far more reliable. But I thought it would be a neat experiment to see the downtime of each site. So I checked it daily just out of curiosity…

Well with today’s apparent disappearance of the NASA JPL site, all but one of my WMS layers mentioned have been down for at least a significant portion of a day. (The only one that’s been consitently up has been http://mesonet.agron.iastate.edu) .

This echos back to what I was complaining about with the whole USGS National Map debacle. The bottom line is that whenever we rely heavily on a web service to deliver essential data, we are risking the integrity of the end product. The chain is only as strong as it’s weakest link and, unfortunately as the USGS and NASA have shown, those links can and will fail completely from time to time.

A while back I wrote about converting KML files into a shapefile for use with GIS apps other than GoogleEarth. I got a ton of emails and site traffic from people looking to go the opposite direction; getting their GIS data into KML.

There are, of course, a couple of utilities already implemented: ArcMap-based extensions including KML Home Companion and Arc2Earth, a nice MapWindow app called Shape2Earth, and the open source WMS Geoserver all support KML output.

Not to be left behind, GDAL/OGR now supports KML output. Oddly enough it does not yet read KML. But hand it any OGR-readable vector dataset and it can be converted into KML. It currently doesn’t offer as much control over the output as the above options but is quicker to implement, works with a wide variety of input formats and can be easily scripted.

This functionality is in CVS only at the moment but should be included in the next release. If you can’t wait and don’t feel like compiling from cvs source, try the 1.0.5 version of FWTools (for Windows and Linux).

The conversion process is pretty straightforward. For example, the following will convert a shapefile (sbpoints.shp) to KML (mypoints.kml).

ogr2ogr -f KML mypoints.kml sbpoints.shp sbpoints

The KML format flys in the face of the GIS mantra stating that content should be seperate from styling. Since styling information is purposefully absent from most standard vector formats, it makes for pretty bland KML output. The attributes just get dumped out into one big text block and there is no classification or styling control.

But in terms of getting your data into Google Earth quickly (esp. point data), the OGR method looks promising.

Wardriving is fun. Going around the neighborhood and mapping all the wireless networks may be nothing more than a geeky hobby but it can sure teach you alot. And viewing the results in Google Earth is icing on the cake.

I’ve used NetStumbler on windows and this works great but since my computers at home are now nearly Microsoft-free, I had to relearn the process on Linux. It breaks down into a few easy steps:

1. Install the drivers for you wireless card. On my HP laptop with a Broadcom card, I followed the instructions on the ubuntu forums which worked great with one exception: the driver link on that page doesn’t have a valid md5 sum so you can download it from this url instead
2. Install gpsd. This is the software that talks to your gps unit and is available in the ubuntu packages through apt. The one hitch is that I had to set up my Magellan GPS unit up for the correct baud rate and NMEA output. Once installed, I connected the GPS unit via a serial port, turned it on and ran gpsd /dev/ttyS0 to start the gpsd server.
3. Install kismet, the wireless packet sniffer. The version in the ubuntu repository is not recent enough to support my Broadcom driver so I had to download the latest source and compile it with the standard configure, make, sudo make install . Then I had to edit the /usr/local/etc/kismet.conf to reflect my system configuration; I changed the suiduser, source and logtemplate variables. Once configured, you can start it with the command sudo kismet.
4. Now drive/bike/walk around for a bit with your laptop and gps unit. When you’re done, shutdown kismet and you’ll have a bunch of fresh logfiles to work with.
5. The main kismet log is an xml file containing all the info on the available wireless networks including their SSID, their encryption sheme, transfer rater and their geographic position via gpsd. I worked up a small python script, kismet2kml.py (based on a blog entry at jkx@Home), to parse the logfile into a KML file for use with Google Earth. It could certainly use some tweaking but it’s a start. To run it, give it the kismet logfile and pipe the output to a kml file:
   kismet2kml.py kismet-log-Jul-03-2006-1.xml > wardrive.kml
6. Now fire up Google Earth (Linux version now available!) and load your KML file.

Also, as James Fee points out, posting your data as KML files means that the data can be integrated into a growing number of kml-ready apps including google maps (just upload the kml and point your browser to http://maps.google.com/maps?q=http://your.server/wardrive.kml).

Another neat application I’ve found for dealing with kismet logs is the kismet2gpx script for converting the kismet gps tracklog into gpx. Since most gps units have pretty tight limitations on the length of stored tracks, logging them to your laptop with kismet could be an effective way of creating detailed tracks on very long trips.