Funny how little it takes to make programmers happy, just make our jobs easier. I mentioned in my last post that AJAX does something fairly obvious and it is a quantum leap in the web browser world. Sadly most people still think of the web browser as the only interface to the internet. Browsers are so needlessly restrictive, I suppose security issues have a lot to do with it, but I think it is mostly a lack of imagination.
That brings me to GML in JP2. Jeff Thurston over at Vector One has a post up which goes into just enough detail to let you know that it is a good idea. Not brilliant, not even tricky in the least. The designers of the JPEG 2000 standard saw fit to allow the addition of text metadata along with the picture in their format. That is all that is needed to add a simple xml file conforming to the GML specification which will allow great things like telling you how the JP2 image(s) are to be georeferenced, you can even add other features like point and polygon features. TIFF allows this as well, but anyone who has looked at the guts of libtiff or seen the contortions need to make an image conform to the GeoTIFF "well known text" spec knows that it is anything but easy.
Why is it a big deal? It is and it isn't. JPEG has comment tags, but I'm not sure if they have a length limit, and I don't really care to check. PNG? same thing. The reason it could be a big deal is because people are talking about it and building a de-facto standard that will be presumably supported in future GIS software. Much like the "well known text" popularized by the ubiquitous GDAL and PROJ.4 packages, a tacit agreement that you check your JP2 images for GML metadata is all that is needed for this to make a significant impact.
But what is the impact of GML & JP2 exactly? By combining the image with the metadata you make distribution, storage, reference and cataloging of such datafiles an order of magnitude simpler. Like my previous post about the "seduction of the one" having one anything makes it so much easier in so many ways. Just think of the all of the possible states inherent in the horrid shapefile format, you have the .shp, the .dbx and possibly the .shx file just to describe some vector data. Right there you have a lot of code to manage all of the possible states of the files. You also have to have data transport functionality that can send and request data from more than one file if needed. It is about an order of magnitude harder to handle a multi-file format than it is a single file one. Not only that, but if you do support a multi-file format you are boxed into not doing something really slick that is only possible from a one file format.
As an example, EarthBrowser v3.0 has a really neat unified data stream architecture internally which I can attach arbitrary metadata to each stream. A simple but powerful concept that can simplify object data interfaces across the board. If I had to make a unified data stream structure that incorporated multiple streams as different parts of the same data, well no thanks. If you really had to do support something like that, you would probably want to pre-process the data to an internal format when reading and just bite the bullet and code it up if you ever had to write that format out.
There you have it; GML and JP2. Highly compressed raster data along with descriptive metadata all in one package. I give it a big thumbs up, at least someone is looking out for us poor overworked programmers.