This weekend I was pinged by Todd Huffman regarding a colleague that is deploying to Los, Nigeria and in search of some good remote imagery to take along.

There were several issues he quickly ran into. Currently imagery is not easy to find for the non-geo expert. The primary interface the broad public is using GoogleEarth which has started doing some nice things with imagery such as time and history.

The second requirement was the ability to run “offline”. Obviously he isn’t going to have any kind of bandwidth for downloading new imagery in the field. GoogleEarth allows you to increase your cache size, and you can “pre-fly” an area to grab data. You could then store this cache (on my machine it is located at /Users/ajturner/Library/Caches/Google Earth) and burn to a DVD or USB stick if you had to move it to another machine.

Let’s do the ‘right’ thing

However, obviously the above solution is bending the terms of service. Probably not a large concern when you’re deploying to the middle of Nigeria – but all the same, DigitalGlobe probably wouldn’t be too happy if you started sharing this imagery.

So my next suggestion was to look for some other source of data – the first of which came to mind is OpenAerialMap. The imagery isn’t nearly as good here, is still under questionable terms of service from iCubed, and is served to the user in tiles. Granted OpenAerialMap is a very new, and as of yet under-served tool. But there are some very valuable lessons from this use case to apply in building out OAM and similar imagery sharing services.

To get the OAM imagery offline there are a few simple approaches. One would be to setup a script to walk the tile pyramid and save the tiles locally. Then use TileCache to serve these off of a disk to a local OpenLayers instance. Not bad – but many new gears and prone to be difficult to maintain.

Peek under the covers

So I began investigating the underlying datasource. Zooming way in to Jos reveals that the imagery is being served by a WMS – a Web Mapping Service.

Clicking on the i-Cubed Landsat copyright link you get the metadata page. The imagery is from 2007 – so not very old, and a very helpful “License: Unknown”, but with a note that the license issue is being worked on. Under “More information” there is now a valuable link to the WMS “Capabilities Document”.

http://hypercube.telascience.org/cgi-bin/landsat7?
request=GetCapabilities&Service=WMS&Version=1.1.1

If you are not familiar with OGC services, the common recipe is that any service provides a GetCapabilities method. This method will return a service definition that tells you what types of data, format, versions, and more that this particular service provides. Unfortunately, in most browsers clicking on the link downloads a “landsat7″ file which does nothing to tell the client (your computer and applications) what kind of file it is. Simple point in why RESTful url’s are much nicer for users. I would have liked to see a landsat7.xml at the very least.

Looking into the file, you can see a number of links proscribed the various methods. However, another problem with OGC Services is that they never actually link to the method or description. In fact, there are 13 pointers to http://hypercube.telascience.org/cgi-bin/landsat7? – the client (developer, application, etc.) is expected to have read the OGC specification document to know that they need to append the request=, and version= and potentially a number of other parameters to actual call that method.

Anyways, RESTful OGC services are a bigger discussion and here we were just focusing on getting imagery before deploying.

The next step is to pull out QGIS, and add the WMS URL. You have the option of several layers. Global is good for finding the region and zooming in – and then you can use the original layer for higher-resolution imagery.

Of course, we could have just used a the WMS URL to GET the image directly – that is, if you know your WMS spec by heart:

curl "http://hypercube.telascience.org/cgi-bin/landsat7?
request=GetMap&Service=WMS&Version=1.1.1
&LAYERS=original&STYLES=&SRS=EPSG:4326
&WIDTH=512&HEIGHT=512
&FORMAT=image/jpeg
&BBOX=9.9,8.8,10,8.9">landsat.jpg

And for more, non-imagery, maps – there is Harvard’s new AfricaMap. It points to 46 topographic and historic basemaps that would be useful to download to a drive an use in the field. For example, to get a topomap:

curl "http://cga-3.hmdc.harvard.edu/cgi-bin/mapserv?
map=/opt/CGA/data/img/uscomp.map
&request=GetMap&Service=WMS&Version=1.1.1
&LAYERS=ONC&STYLES=&SRS=EPSG:4326
&WIDTH=512&HEIGHT=512
&FORMAT=image/png
&BBOX=8,8,10,10">topomap.png

So the answer was – there is some data out there, definitely not as high quality and resolution as the proprietary datasets. And even when there is data, it’s still very difficult to find and utilize. Vector data is finally becoming common (to find, search, and create) but there are still large steps to make raster data as easy to use for non-experts.