Sat, 25 Feb 2006

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.

Thu, 17 Mar 2005

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.

Sun, 13 Mar 2005

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.