Tuesday, March 31, 2009

Using MapTiler to Display Aerial Imagery from MrSID files


The map tiler progam is a GUI for the GDAL2 command line utility. I am going to hopefully use it to construct a system of map tiles. Google uses map tiles to display imagery; each section of a picture you look at is one tile, and within that tile are smaller tiles. The power in this tiled architecture is that it allows you to zoom in on a portion of the image and not have to look at all the zoomed in portions of that image. This type of architecture is obviously well-suited for the web; but it takes some doing to get it working.


The problem that I encountered with imagery is that the google imagery that is available for Bremerton isn't sufficient for what I need: that is, the houses and parking lots and other impervious surfaces aren't really available at a viewing zoom that would allow our customers (using a version of the map that I'd be serving) the ability to see their surfaces in the detail that they will want to make an assessment of the correctness of the polygons that I've drawn for them. AT least, I wouldn't be satisfied if I was them. Further zooming doesn't produce fuzzy imagery, it produces no imagery and the minimum zoom level available is too far out for easy discernment of property borders and resolution of other salient features of physical geography.

So, what do we do?

Well, one nice thing about google is that they've got a good bead on a solution to just about any problem that folks have. The solution to this particular problem is custom map tiles. Custom tiles are images that are hosted from someone other than google - and are displayed in the basemap of the image just like the regular satelite imagery. So, for instance you could upload a high-resolution image of a particular rooftop and specify that this tile be displayed for zoom levels 14-16 (the greatest zoom levels, and the point at which the satelite imagery coverage for Bremerton breaks down). This way, when a customer zooms all the way down to their house, instead of seeing a message that no imagery is available they'll see the imagery from the custom tiles that I've put there for them to see. Simple enough huh?

Well, it might be.

The trick is that we have to create the imagery in a way that it is easy for Google to integrate it into their program. That's where this MapTiler program comes in - this program takes high-resolution aerial imagery from a number of different sources and file types and converts it into the same map tiles that google uses to add imagery to its site. EAch of the tiles has to be 256x256 pixels, and there are different tiles for the different zoom levels of imagery you want to display. In addition, the tiles are ordered (either by their attributes or by filename) so that they are easy to assemble - this involves a simple numbering scheme of #1,#2 where #1 is the the vertical row number for the tile, and #2 is the horizontal row number of the tile. A simple 9 tile schema would thus be attributed:

1,1 2,1 3,1

2,1 2,2 2,3

3,1 3,2 3,3

And because we know that each tile is 256 pixels - we know that this little example has the dimensions of 768 x 768 pixels. Now imagine that - but hundred of thousands of pixels down and across and you get the idea of the immensity of scale we're talking about. But, supposedly, maptiler can do it: can take our really big imagery files and chop them up and number them appropriately. ITs supposed to be as easy as running the program and then taking the folder with the files to your hosting server and they should load once you make the appropriate reference calls to load them.

We'll see.

The filetype we're working with in this instance is multiresolution seamless image database files (MrSID). This is a filetype that was developed for Nasa and other organizations to easily display large amounts of high-resolution imagery and is something of an industry standard when it comes to display, recall, and processing of high-resolution imagery for GIS and other applicaitons.

Mr. SID is great - but the MrSID files are single georeferenced orthoimages (or mosaics of single images). They are a picture, and you can hang them in 2D space in the correct place. But, they aren't the flavor, arrangement, or numbering the gooogle maps API needs imagery to be in for seamless display over the web - so we need to process and convert them to get them to look like something google maps will want to display for us.

Hopefully, we'll process the images and get them to be diplayed when we go to the appropriate zoom level in google maps. IF that's the case - we're in like Flynn. There's also another reason I didn't want to use google satellite imagery: our ortho-referenced imagery doesn't quite line up with theirs. The reasons for this are various: most of the difference has to do with the correction of orthagonal and isometric variance due to the reference point of the camera when it took the imagery. Some of the images were stretched just a little and others were zoomed in or out just a bit so they fit with the tiles adjacent to them perfectly. It isn't much - and when you view the complete city of Bremerton aerial mosaic it is presented as a single seamless photograph, with differences that are scarcely noticeable. But; the google imagery isn't corrected or massaged in this manner: the imagery on google is from Satellites, which means that the pictures were taken from straight up - not from an angle or off to hte side (however slight), and that means that all of those corrections that were made represent differences in the imagery between matched-coordinate site comparisons. It isn't something that is easily corrected for - it isn't as if all of the coordinates of our imagery are off to the left 6 pixels: that would be easy to fix. The end result of this is that if I am in ArcGIS and I digitize some Impervious Surface feature from our digital imagery and I take that feature over to google maps and display it in exactly the same place on the map, the feature polygon that I drew doesn't sit exactly on top of the structure I want it to. It overlaps with that structure, and you can tell that the polygon certainly represents that structure and not another one - BUT, the differences between the location of the structures (as well as their orientation and isometric conformation based on the location of the camera) make the polygon look wrong. The last thing I want to do is create a mapping condition that makes people think we measured their Impervious Surfaces incorrectly. I decided a while ago I wouldn't be able to display our polygons over google's imagery correctly: but if I can replace it with the imagery that I worked off of to create the map - the polygons will look correct, AND the imagery will be of a quality and zoomability that will make the map really useful. Its the best solution. The next best solution is to simply not display any imagery at all, and while that works it isn't a solution that's going to win me any accolades for inventiveness. The custom tiles solution is pretty sophisticated - but if it works I'll have built a map base that will serve our purposes wonderfully: and in addition, I'll have added another REALLY important skill to my GIS toolkit.

---------------------------------------

The interface for using MapTiler is pretty straightforward. The only bump I encountered was finding the correct number for the projection I use to display the SID files. The georeferencing for the shape files is actually a projection, and that means you ahve to get exactly the right one. We use a NAD83 lambert conical projection derived just for Washington State and to find that I had to go and look it up. It took a bit to find, but if one is using the more common projections it should be a lot easier.

After all of the settings are loaded, the maptiler program does its work. It took 3 whole days, day and night, to render the maps I needed from the shp files. When it was complete though, the finished product was pretty amazing: you have a directory filled with subdirectories with the images you need and in root: you've got a few files - one of them is a google map HTML page that loads the images. A second file does the same thing but for the openlayers maps API. I haven't used the latter, but the former is meeting my needs - this file can be easily augmented to include the bells and whistles you like to have in your map. For me, this meant adding in the geoXML overlay for the polygon KML's that I was creating from the impervious surfaces for the city.

Would you like to know more?...