Technical Ramblings

In order to use TileCache to cache tiles for use in the Google Maps API, you need three things:

• A WMS server which supports the spherical mercator projection
• A properly configured TileCache pointing to it
• A small snippet of code to add a custom TileLayerOverlay to your Google Map
• A small snippet of code to add a custom TileSource to your Virtual Earth Map

WMS Server

My experience is with MapServer, so that’s what I’m going with here.

MapServer uses proj.4 for its reprojection support. In order to enable reprojection to Spherical Mercator in MapServer, you must add the definition for the projection to your proj.4 data directories.

On Linux systems, edit the /usr/share/proj/epsg file. At the bottom of that file, add the line:

<900913> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 
               +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs

After you do this, you must add the projection to your wms_srs metdadata in your map file:

map
  web
    metadata
      wms_srs "EPSG:4326 EPSG:900913"
    end
  end
  # Layers go here
end

This will allow you to request tiles from your MapServer WMS server in the Spherical Mercator projection.

Configuring TileCache

Your TileCache configuration will need to point to your WMS installation, using the parameters suggested for Spherical Mercator in the default tilecache.cfg.

[google-tiles]
type=WMS
url=http://labs.metacarta.com/wms/vmap0
layers=basic
extension=png
bbox=-20037508.3427892,-20037508.3427892,20037508.3427892,20037508.3427892
maxResolution=156543.0339
srs=EPSG:900913

Here, you can see that I’ve used the MetaCarta Labs vmap0 WMS. If you’re using a standard MapServer WMS, you might have a url more like:

url=http://example.com/cgi-bin/mapserv?map=/mapdata/mapfiles/vmap0.map

Setting up Google Maps

Finally, you must make a GTileLayerOverlay for your tiles.

 
    var myTileLayer = new GTileLayerOverlay(new GTileLayer(null,null,null,{ 
      tileUrlTemplate: 'http://example.com/tilecache/1.0.0/google-tiles/{Z}/{X}/{Y}.png?type=google', 
      isPng:true})); 
    var map = new GMap2(document.getElementById("map_canvas"));
    map.setCenter(new GLatLng(0,0), 0);
    map.addControl(new GSmallMapControl());
    map.addOverlay(myTileLayer);

The ‘type=google’ flag on the end of the URL tells TileCache to use the “Google-style” 0,0 in the upper left corner.

Once you’ve done this, you should have a TileCache layer on top of your Google Maps base layer. You can see an example of this setup, just for proof that I’m not putting you on. 🙂

Virtual Earth Javascript

“But I don’t like Google!” you say. “I want VE!” Well then, why aren’t you using OpenLayers already? I mean, that’s what it’s for, right? 🙂

More seriously, VE isn’t much more difficult:

    vemap = new VEMap('myMap');
    vemap.LoadMap(new VELatLong(0, 0), 0 );
    //Add layer
    var tileSourceSpec = new VETileSourceSpecification("mclabs", null, 1, 
       [new VELatLongRectangle(new VELatLong(-86,-180),new VELatLong(86,180))], 
       1, 16, function (tileContext)
{
   if(tileContext != null && tileContext != "undefined")
   {
      var key = tileContext.ZoomLevel+ "/" + tileContext.XPos + "/" + tileContext.YPos + ".png?type=google";
      var path = "http://example.com/tiles/1.0.0/google-tiles/" + key;
      return path;
   }
}, 0.8, 100 );
     vemap.AddTileSource(tileSourceSpec);
    
     var tileLayer = new VELayerSpecification(VELayerType.VETileSource,"mclabs","mclabs");
     vemap.AddLayer(tileLayer);

And, for your viewing pleasure: an example of the same tileset in use.

KML has become the “HTML” of the Geographic Web. With limited semantic meaning, a combination of mostly-human understandable XML tags for the majority of the usages, widespread use and abuse for purposes far beyond the original thoughts and intentions of the designers, and more, KML fits well into the geographic version of the niche filled by HTML in more generalized content publishing.

Google Earth loads *content* over the web, rather than loading code like Google Maps mashups do. The difference is important: Google Earth ‘mashups’ generate content which is, to some extent reusable within other applications. Google Maps mashups don’t: they tend to use hidden databases without public APIs, and the HTML and code that you do see is executable code, not content.

The content that is generated is reasonably easy to follow: KML is reasonably close to human readable. There doesn’t tend to be a lot of extra XML that confuses users: similar to HTML, it can be edited, for the most part, in a text editor with limited difficulty. There’s a caveat to this, however: editing geographic information — the actual coordinates behind a ‘FlyTo’ — is something that humans don’t have an innate ability to do.

To this problem, Google Earth offers a solution: In addition to being a KML viewer, it’s also a KML *generator* — draw any type of feature you like, style it how you like, then just select the item and ‘copy’ the item, and paste it into a text editor: You immediately have a working KML file, with coordinates that you created. WYSIWYG editing, built right into the data browser. Google Earth acts as the ‘view source’ button for the geoweb.

To some extent, this is extremely handy: users now have the ability to trivially create styled content in Google Earth, export it, and mix and mash these items together to create their own customized feed of data. However, this democratization is exactly the reason that KML does fit the bill of the “HTML of the GeoWeb”, with its pitfall as well as its benefits.

One of the key aspects of the difference between “paleogeographers” and neogeographers is the difference in the importance of accuracy. (I use the terms lightly here, since I don’t tend to categorize users in that way, but it provides a spectrum which is useful to understand.) In general, GIS professionals — regardless of what toolset they’re using, be it Google Earth or ESRI ArcMap — have a need for an understanding of the quality of their data. It doesn’t have to be perfect for all cases, but knowing how good it is or isn’t is an important distinction when you’re going to make decisions based on it. Google Earth doesn’t make including information like this a part of the KML workflow, nor did KML accommodate this type of usage very well until relatively recently.

Information like attributes of a feature, source data — in fact, metadata at all — and so on, is largely left out of the realm of KML. Similar to HTML, it’s largely treated as a ‘presentation’ language by the majority of the users of it. (FeatureServer uses it in a different way, and OpenLayers mimicks that usage, but that’s the exception, not the rule.) Although HTML in an ideal world separates style from substance — using CSS, semantically correct tags, etc. — I think that most web developers have seen too many uses of <table> for layout to believe that that ideal world actually exists. Similarly, KML has support for many features that users will never use. Separation of content and style is possible, but not as widely used, and mixing presentation with content (in terms of application-style control) is the best practice behavior for KML.

I’ve seen continued belief by some users that KML is a geographic data interchange format. Although exchanging geographic data via KML is possible, it’s not an interchange format for data: it’ s primarily an interchange format for presentation. Tools like GDAL and other geodata libraries do their ‘best guess’ interpretation of this data as geographic data, but are not well suited for presentation, only data interchange.

OpenLayers, on the other hand, is in a position where presentation can be taken into account. The newest version of OpenLayers has support for a fair amount of KML styling: other than differing default styles, this KML file looks pretty similar in OpenLayers and Google Maps. However, even here you can see the comparative limitations: Since OpenLayers is primarily about rendering maps, the ‘extras’ around the outside are lost, a somewhat significant loss in cases where most of the information is provided via additional display.

In the end, Google Earth is currently the only reasonably complete KML browser (that I’m aware of). Google Maps and Virtual Earth are slowly improving, and OpenLayers is moving forward as well. I look forward to seeing continued development, and am hopeful that the open source geospatial community can build UIs around data like KML that allow the feature rich presentational options that are currently available via KML in Google Earth — even if we’re only in 2d space. Solving the problems of implementing a format as far-reaching as KML is quite a task, and I’m enjoying watching as users demonstrate their interest in a particular set of features by helping to implement them, and look forward to continuing to see the trend of high quality presentations of geographic material grow, both in KML and other arenas.

One of the cool things about building a map on top of quality Open Source products is the ease with which one can extend the possible uses of your software.

GDAL 1.5 has gained the ability to read a WMS-C style remote tile cache directly: this means that any tool which uses GDAL as an image provider can read remote tile caches directly. The one that matters the most to me is MapServer: MapServer has the ability to load up a simple config file — http://openaerialmap.org/static/gdal_wms.xml — and use that in a mapfile: Using With MapServer.

Not running the bleeding edge GDAL? That’s fine: Instead, you can use the WMS that’s hosted by the OAM project: Using With WMS. This means that any WMS client — including those fancy schmancy ESRI tools that speak WMS. (There are at least some of them, I think.)

Your application only speaks in WorldWind? Well, we can take care of that for you: With a WorldWind metadata file, you should be up and running in no time. (In my experience, unfortunately, this is true in ossimPlanet, which has no problem with the file, but WorldWind itself seems a bit touchy about it once you zoom past the first couple levels. But I can only do so much.)

Using the new plugin-friendly TileCache that I rewrote last night, I was able to add support for the Mobile GMaps client — Using With MGMaps — in just 20 minutes. Similarly, a user reported success using the tiles with Maemo Mapper.

Of course, it can be used with OSM — either as a tile backdrop, or in the OSM editing application (JOSM): Using With OSM — due to the above plus TileCache’s TMS support.

As a result of the TMS support, it should be possible to load into Google Maps as well, though I’m really too lazy to test that one.

Overall, with just a few small tools — GDAL, MapServer and TileCache — it’s possible to build support for a wide variety of services from a single dataset.

For the record, from the OpenLayers IRC:

The Satellite tiles from Google Maps appear to be dead. This is not a OpenLayers problem — This is also happening on Google Maps homepage.

So don’t blame me! 🙂