Tile Map Service Specification

On the OSGeo website there is a new posting describing the “Tile Map Service Specification”:http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification

From the Document Scope:

“This standard specifies the behavior of a service that provides access to georeferenced maps in the form of a regularly spaced set of regularly sized squares at a finite number of scales. This standard specifies operations to retrieve a computer-readable description of the service instance and to retrieve particular tiles.

A Tile Map Service provides access to cartographic maps of geo-referenced data, not direct access to the data itself. This document standardizes the way in which map tiles are requested by clients, and the ways that servers describe their holdings.”

It is nice to see the use of tiled map libraries becoming more visible and getting some respect. Post MrSID and ECW there was, I think, a presumption that technology like image catalogs were “old technology” and we know what such a pejorative tag being “old” is in a buzzword driven world of modern IT.

(My view has always been that a professional in the geospatial industry should know the science behind the technology we use and be able to select the most appropriate for the job at hand. ECW, MrSID and JPEG2000 because of their use of wavelet compression techniques are appropriate for certain types of data – mainly photography and satellite imagery – and in certain types of application use but not for cartographic maps generated from vector data.)

It appears that the increased visibility of Tiled Map Services such as Google Maps etc, has meant that the issue of image catalog use is being revisited.

About time.

I have had a brief read of the specification and can see that an image catalog created using my Image Catalog Tool could be served over the web as a Tile Map Service via a suitable interface.

A few observations though. The specfication says:

“The Tiled Web Service provides access to resources, in particular, to rendered cartographic tiles at fixed scales.”

Why does the specification continually refer to the tiles having been cartographically rendered? Perhaps this is just semantics but I have never thought of an orthophoto or satellite image as being a “cartographic rendering”! Yet these can be stored in an image catalog and delivered via a Tiled Map Service.

Secondly the specification talks about “fixed scales” and even has these in the XML reponse:

 <TileFormat width="256" height="256" mime-type="image/jpeg" extension="jpg" /> 
  <TileSets>
   <TileSet href="http://tms.osgeo.org/1.0.0/vmap0/levelzero" units-per-pixel="0.703125" order="0" />
   <TileSet href="http://tms.osgeo.org/1.0.0/vmap0/levelone" units-per-pixel="0.3515625" order="1" /> 
   <TileSet href="http://tms.osgeo.org/1.0.0/vmap0/leveltwo" units-per-pixel="0.17578125" order="2" /> 
   <TileSet href="http://tms.osgeo.org/1.0.0/vmap0/levelthree" units-per-pixel="0.08789063" order="3" /> 
  </TileSets>

Now my Image Catalog Tool does not enforce a single fixed scale for all tiles stored within it. Yes, it allows for the setting of a minimum pixel size but individual tiles could have greater resolution. This seems to me a more natural thing to do where image catalogs are being constantly added to. For example, at my last employer, spot aerial photography was done to cover forest operations as they commenced during each year. The spot aerial photography was done using digital cameras and low flying aeroplanes yet correctly orthorectified. The resultant imagery was, because of the method of capture, variable in scale (though the pixel resolution was approximately the same). Perhaps I should consider creating a property (managed by the Catalog Registry Tool) that enforces the minimum pixel size as the fixed scale for the catalog. (If any user of the tool wants this let me know.)

The specification also seems to assume that an image catalog underneath a Tile Map Service has a single area of coverage. That is, that the whole of the area defined in the bounding box xml:

 <BoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />

has tiles and that the tiles contain real data.

My experience in using image catalogs within a dynamic business is that often this is not the case. Because of this I added in the automatic management of a @<image_catalog>_boundary.shp@ shapefile. This shapefile contains a single multipart polygon that is the outer boundary of all existing tiles (in my image catalogs not all tiles have to exist). This is done by unioning all the tile boundaries together after any edit operation.

Just some simple observations on image catalogs and the new Tile Map Service Specification. Regardless as to my quibbles with the assumptions in this standard, I am genuinely pleased to see that the need for such as specification has resulted in it being created and published.

Simon