Russ Nelson : gis

World Wind and shapefiles

How should NASA's World Wind handle the introduction of a shapefile layer? Well, I can think of two reasonable ways to do this.

somewhere there exists a .zip file containing the three component files of the shapefile. A third party has written an XML which describes how they want that shapefile drawn (e.g. with and without labels). Their XML file specifies the URL of the shapefile.
somebody wants to publish a shapefile directly usable by WW. They create the .zip with the three shapefile files, and add to it the .xml needed by WW.

I can think of only one benefit to #2: you don't have to deal with telling your webserver that a .xml file is an XML file rather than some kind of mutant HTML. A big advantage of #1 is that anybody can describe anybody else's file for use in WW, *and* they don't have to host that shapefile.

We could support both formats, of course. If you tell WW to use a shapefile, WW could look at the filetype / extension. If it's XML, then the XML specifies the shapefile with a URL. If it's .zip, then the .zip contains the XML file.

Now, the second question is how to handle versions. Is there any reason to keep permanently a shapefile given that WW doesn't permanently keep any imagery data? Basically, WW is an online data viewer and only caches imagery data. Why should it save a shapefile? Thus, whenever you turn on a shapefile, WW should re-fetch the shapefile (checking the HEAD just as a web browser does). If somebody *really* wants to display local data, they can specify file:// as the URL.

LatLonUTMconversion

I've been doing a lot of work lately on mapping. If you go look at the bicycling category, you'll see some of it. I need to improve the programs that make those maps, but once I'm satisfied with them I'll publish them here. Most generally I want to do GIS-style analysis of maps, only without using a GIS package. The most capable open source GIS package is GRASS, but it has an incredibly steep learning curve. I've tried to learn to use it twice now, and can't get up the slope. It's easier to write my own software than to learn to use GRASS. So that's what I'm doing, and you'll find all of my Python GIS software at pygps.

In particular, today I'm releasing the LatLonUTMconversation library. It converts (predictably enough) between latitude and longitude and UTM coordinates. A GPS receiver will give you lat/lon, but UTM (Universal Transverse Mercator) coordinates are more useful. For one, you can compute distances using them, since each integer UTM tick is one meter. For another, you can locate a point on a map by simple subtraction and division by the scale of the map.

Color Ortho Quads in NY

I recently found out that (somebody) created color orthographic quads of New York State. Look for your county on the NYS GIS site. Naturally, instead of publishing them in a lossless open format, they're published in the proprietary MrSID format. This is a wavelet form of compression similar to JPEG2000. There's a decoder called mrsiddecode which creates .tiff or .jpg files as you wish.

I'm in St. Lawrence County (below left). They have complete coverage for 60cmpp colorized infrared (cir) quads (below middle). Unfortunately, they only have partial coverage for 30cmpp color quads (below right). For St. Lawrence County, they only cover Potsdam, Canton, Massena and Ogdensburgh. A friend of mine, Simon St.Laurent, is another map geek. He lives in Dryden, NY, located in Tompkins County. I notice that Tompkins only has 30cm cir and 20cm cir coverage, and no color quads at all. So apparently the phrase "your mileage may vary" applies in spades.

In order to use those images, I turned them into 200x200 pixel tiles similar to those published by Terraserver. Those tiles get thrown into an in-filesystem database which is a sparse local copy of Terraserver. Whenever any of my mapping software fetches a map from terraserver, it populates the database with it. I've only published pygps and mapview. I haven't yet published maptracks (makes a map with a GPS track overlaid), make-tiles (which splits up the color ortho quads), nor make-tiles-index (which creates the coverage maps above). They need improvement before they're seriously usable.

These datasets get very large, by the way. I've recently discovered the magic of external hard drives using USB 2.0. I picked up a 120GB Western Digital drive from Office Max for $60. The ortho quads amount to 3.9GB, but if you uncompress them all to .tiffs, you'll fill up all 120GB. I need to uncompress on the fly with make-tiles.