Image Tile Caching, rehashed

A little more than a year ago, I wrote about my rather simplistic approach to caching image tiles for the interactive map viewer on PhilaGeoHistory.org. Since that time, I’ve made a few updates that are worthy of a reposting, particularly if you want to use the code for anything.

First, one of our partners, the Free Library of Philadelphia, wanted to use the script, but wanted it in ColfFusion. So I migrated it from PHP to ColdFusion. The two versions work very similarly, so you can see the current version in PHP or ColdFusion.

Second, here are the new features:

  • Store the cached images for different layers in different directories. Seems simple enough. I hesitated to do this previously because you could request multiple layers at once through the WMS script, but in practice I’ve never done it.
  • In ColdFusion, open the resulting image to make sure it is a valid image. Sometimes the file that is returned is garbage, or just an error, and you don’t want to cache it. Also, if the PNG file is smaller than 1K, it’s most likely not an image at all.
  • If the first attempt to retrieve an original tile fails, or results in an error, retry the http request again.
  • Use an appropriate file extension denoting the format of the image. Previously, just the hash of the request string was used as the filename. Now it’s the has plus the correct extension. Makes it possible to set the correct MIME type when serving up a cached image, and makes viewing problematic images in the file system a lot easier.
  • Return an HTTP header telling the client to cache the image. The results of dynamic scripts in general are not cached by browsers, but in this case, significant speed benefits arise from holding onto the images, which are very unlikely to change in any short period of time.

Further features that would be useful include recognizing the geographic extent of each layer and not caching tiles outside of that extend; recognizing empty tiles; and more efficiently storing the resulting cached files.

I don’t expect to invest too much in this, especially since there are much larger systems to do things like this (TileCache is one example). Currently, it’s too complicated for me to consider implementing, but if I need more features, or the project scales larger, I’ll have to migrate to something like it.

Georeferencing DPI Quirks

TIFF files have horizontal and vertical DPI numbers set in the header. You can use a program like IrfanView to see and set the values.  Turns out the DPI settings have an impact on how ArcView handles coordinates for geo-referencing.  So here’s a little reference.

  • TFW world files do not seem to use the DPI values, and use straight pixels.
  • AUX.XML files, produced by the newer versions of ArcView, do use the DPI values. The list of X and Y points created during geo-referencing are the pixel location divided by the DPI value.
  • TFWX files, produced in association with AUX.XML, are just plain old world files. So if you happen to correctly resample (change pixel dimensions and DPI, such that the “inches” are still the same) a file that has an AUX.XML and a TFWX, it will display just fine in ArcView. However, a program that can’t read the AUX.XML and relies on the TFWX instead, will not put the image in the right location.

Beware that when you convert images from one format to another, you might lose the DPI setting.  JPEG and ECW files, for instance, may not have any DPI set at all. So when converted to TIFF, ArcView sees no values and uses straight pixels.  If you then open that TIFF file in Corel PhotoPaint (or perhaps Photoshop), the DPI is set to a default, like 72 dpi, and saved with the file. Suddenly the points don’t work any more, and if you reload from the saved text file of points, it still won’t work.

One last hint: you can use Excel to open the points (.txt) file and change the X and Y values in the first two columns.  If you go from a file with no DPI values to 72 dpi, divide each value (only the first two columns) by 72.  Probably can do this in the AUX.XML file too, but you’ll have to write some XSL or do it by hand.

Converting UTM to Latitude and Longitude in ColdFusion (CFC)

In the National Register location data, everything is plotted with UTM coordinates (zone, easting, and northing).  I want to use this location information in work I’m doing on PAB, which at the moment requires me to convert everything to latitude and longitude.

I could do this in ArcMap, and reproject the whole dataset.  But I want to write an automated import script for NR data, so I had to find code I could use in ColdFusion separate from traditional GIS software.

Found paydirt in Chuck Taylor’s GIS toolbox.  He has a javascript version of the conversion routines, so all I needed to do was migrate that to a ColdFusion component (CFC).  Having freely received, I’ll freely give — here’s the CFC for converting UTM to latitude and longitude.  No restrictions attached.

Image Tile Caching

Update (Oct 2, 2009): I’ve written a new post with links to newer versions of this script. Make sure you use the code there, not here.

For the map mosaic viewer I’m working on, the images are generated by ER Mapper’s Image Web Server from the source JPEG 2000 and ECW files. It works great, but can be a little slow, as it has to load very large images (equivalent of 100GB uncompressed) and pull tiles out. Because the viewer always uses the same tiles at each zoom level (defined by a lat/lon bounding box), it made sense to cache the images.

A real simple PHP file seemed to do the trick:

Continue reading

Mosaics of Old Maps

One of the really cool projects that I get to work on is building indexes and access systems for the various maps that become part of the Greater Philadelphia GeoHistory Network. (In case you don’t want to read the rest, just check out the beginnings of something I’m working on. View the map, then click “LUM 1942.”)

Many of the maps that were scanned so far are from old atlases, ranging from 1858 through the early 1900s. Then there are two sets of land use survey maps that were produced by the Works Progress Administration in 1942 and 1962. (Wikipedia says that the WPA was shut down by Congress in 1943, so I’m not sure where the 1962 set came from, but that’s what the title sheet says…)

Anyway, I’ve been having fun with the 1942 set of the Land Use Maps. The maps are arranged in a grid of 100 plates that covers Philadelphia, and are pretty straightforward to navigate. But in this modern day and age where Google offers a seamless coverage of the whole earth, who wants to flip through individual plates?

Enter the mosaic.

Continue reading