This past weekend, I created a map of one of the sensor rides I made this past summer. The tool I used was OpenLayers, a full WMS mapping client written in JavaScript(!). Let me repeat that: the whole thing is written in JavaScript–there are no server dependencies, besides the WMS servers. It’s really amazing, actually.

I started creating my map by modifying an example I found on the OpenLayers site. It had a reference to TIGER data already in it, so I could see the streets of Pittsburgh. TIGER data is the stuff from the Census Bureau. It’s free, since it’s US Government created, but it’s also horribly out of date–Three Rivers Stadium is still in there; it was demolished in February of 2001. Many streets were also labeled incorrectly.

I continued by adding a layer from Pennsylvania’s PAMAP program; satellite imagery that is much more current. I found this data through PASDA, an excellent resource for Pennsylvania spatial data, by the way. Kudos to Pennsylvania for releasing this imagery (I guess they have to?)–it’s “Google Maps quality” (i.e. the high-resolution stuff you used to pay big money for), but free of watermarks and free to access via WMS. They even have the entire state covered.

One caveat I ran into while adding the data to my OpenLayers map was finding the “layer name”. I didn’t specify this correctly at first, and instead of satellite tiles, I got a stretched image that said “bad layer name” or some such thing. The solution was to get the WMS metadata and look at it to find the layer name. In my case, the WMS service was at this URL, so I needed to request this URL (note the extra parameters at the end), and look at the resulting XML for the “Layer” elements. In each of those there is a name attribute–that is the name you need to use when initializing WMS object. Considering all this, my call to the constructor ended up being (all one line):

var wms_pamap = new OpenLayers.Layer.WMS( “PAMAP High-Res Imagery”, “http://maps.pasda.psu.edu/wmsconnector/com.esri.wms.Esrimap?Servicename=PAMAP_AerialPhotography”, {layers: ‘2545811822′ }, {numZoomLevels: 16});

Getting the satellite data on there, I had a pretty full-featured map. Next was to add the path of my ride. I had this in KML already, since I had previously visualized this data in Google Earth. I added the layer with OpenLayers’ KML support, but I found a problem–a bug in OpenLayers prevented KML data from displaying correctly when the files were large. The issue had been partially addressed by somebody else–I finished the job, and submitted a patch (still needs unit tests).

I finished up the map by writing a simple JavaScript function to take data from a static data structure I hand-populated, and create markers from them on the map. Each marker annotated a point where I saw a spike in the recorded gas or noise levels along my ride.

The final map’s files are available here for you to download and see. In the end, I think the map came out nicely–given more time and more familiarity with the framework, I hope to make the line representing my ride vary in color or size to indicate the level of gas or noise present there. But it’s a prototype.

The promise of OpenLayers seems really great–a portable, open source, client-side, web-based spatial data viewer. Given the increasing popularity of spatial data and mapping in general, I think this will be very useful for those wishing to provide or collect data to/from the public. You could use Google Maps to do this, yes, but who knows when Google might start putting strategic ads on your maps? Besides, it’s Google. Don’t they control enough information already?

The only caveats with OpenLayers I ran into were the complexity of OpenLayers and its API (it’s *really* full-featured), and the variability in the quality of WMS servers. OpenLayers delivers on its end of the bargain–it visualizes data available through a WMS. Unfortunately, however, WMS servers have no such uniform code of good behavior. The PAMAP data, for instance, kept going in and out on a Friday night. Perhaps I was accessing it during the server’s maintenance window? I also tried to add a layer of projected ozone concentrations from the NOAA, but that WMS didn’t respond at all. This sort of issue brings up an important caveat in the age of distributed computing: differences in the availability of resources, bandwidth and care taken when managing the machines that serve you implies risk if you begin to rely upon them for your operations. At least Google has an incentive (a financial one) to keep their machines running; the state of Pennsylvania? Well, I don’t know… they do try, I guess.