TransDEM Forum

Around 10 years ago I added online access to TransDEM, first WMS, Web Mapping Services, then Map Tiles, both well-known industry or de-facto standards. Map Tiles, also called Tile Maps, have become more and more popular over the years. One of the reasons probably is that Open Street Map makes use of them. Originally, however, these were introduced as free services by Google, Microsoft and a few other commercial data providers.

The map tile web service interface itself is rather simple, but the composition of the request URL is not. The URL asks for a specific tile by its address and that address automatically implies georeferencing. In return, you get a bitmap of 256 x 256 pixel, one tile. The whole thing is designed as a quadtree and the underlying projection is standard Mercator. But you will need some background knowledge to translate from a geographic location to a tile address. Google and Microsoft offered Javascript libraries to handle this for you, for the most typical application domain, the website.

With more powerful servers on hand, Google and Microsoft later offered new interfaces, that made it easier for the client side. While still using the quadtree structure internally, the newer interface asks for direct input of geographic coordinates and the resulting bitmap can have somewhat more flexible dimensions. URL compositions now look similar to WMS.

There is a catch. The newer interfaces are bound to new services and access is no longer anonymous. Instead, they require a key.

Basic keys are “free” with both Google and Microsoft, but, as we all know, there ain't no such thing as a free lunch. You pay with your data, or, as someone put it, when consuming a free product the user himself will become the product.

Hence, I have always been very reluctant to implement other than anonymous access clients in TransDEM.

During the last couple of months, however, a number of indicators have appeared which could suggest that at least Google may shut down the original anonymous map tile service in the not-so-distant future.

From the feedback I receive, many TransDEM users start with Google Earth. Not everyone is used to reading maps, particularly topographic ones. Aerial images seem easier to understand, and for many areas you can blow them up to the utmost detail. Google Earth functions in TransDEM are easy to handle, with very little preparation needed. But when the number of images increases the whole process becomes a bit cumbersome and you will look for partial automation. Map tiles offer remedy. A different interface to basically the same data. TransDEM will handle image acquisition, georeferencing and conversion to UTM. And, when working along a path, the map tile client even handles entire series of images.

We would lose all this automation for aerial images if Google and Microsoft retire their classic tile services.

For that reason I have decided to add support for the newer map services that require a key. I will try to hide the underlying procedures to contact the new servers as much as possible and plan to integrate this new variant in the existing Map Tile client. In the ideal case users will not notice any difference in the resulting bitmaps between the classic and the key-based servers.

TransDEM will not come with any key pre-installed. It will be completely up to the user to obtain such a key through the Google or Microsoft registration channels. Even with a key, access to their services will be limited. Free keys will have a lower quota than paid keys, but should be sufficient for our purposes. TransDEM will offer a dialog to store the key in the settings, separate from the common map tile settings.

If you have used Rail Simulator/Railworks and their Google Maps support, you may already have come across that key mechanism.

At the moment I do not yet know how long the implementation of this new service interface will take, since I have just started with the basics. I'll keep working on it and will update you once there is news.

In defense of the choice to use the 'easier' google earth, its worth noting that many areas of the world never had detailed topo maps produced, and of those that did, many of those maps are not available freely online.

Im using GE because Im used to it, but not before I exhausted my search for topographic data covering my route area.

Some people will have noticed: Google Maps via the classic TransDEM Map Tile client stopped working for ortho-images in mid September.

Fortunately, my implementation for the alternative API key access is nearly finished - despite a necessary interrupt for some holidays - and will be released as TransDEM 2.6.1. It will work with Google Maps and Microsoft Bing Maps (aka Microsoft Virtual Earth). As intended, users will not note much difference, if any at all. Users must, however, obtain such an API key themselves and register with Google and/or Microsoft. TransDEM will provide the means to use the key but not the key itself. I will publish tutorials on how to register and create such a key. Rail Simulator/Railworks route builders may already be familiar with this procedure.

(API stands for application programming interface and is a commonly used term do describe the outer or public interface of software libraries and web services.)

While TransDEM will support the API key for Google and Microsoft, at the moment you will only need this method for Google ortho-images. At the time of writing, all other tile types for Google and Microsoft, including Microsoft ortho-images, are still accessible via the classic web interfaces that do not require any key.

Let's see how it looks like.

We start with the classic way, a preview for Mirosoft ortho-images, the idyllic timber-frame town of Stolberg in the German Harz mountains:



Now the same preview via the API key interface:



Basically the same. I deliberately picked the combined ortho-image/label type because that turned out to be the only type with any visual differences at all.

Technically, however, there are some substantial differences. The classic web service delivers tiles in a predefined coordinate raster (quad tree) and a fix size of 256 x 256 pixels. For the preview of 512 x 512 pixels, TransDEM acquires 4 tiles:




With the API key service, the tiles still exist but will be combined on the server side and the user is no longer restricted to the exact tile coordinates or the exact 256 pixel tile size. However, to be fully compatible with the classic tile system and the existing map tile implementation, TransDEM will continue to use precise tile addresses, now converted to WGS84 lat/long. As said, the API key web services allows for somewhat larger clippings. TransDEM will make use if this feature and go for 512x512 pixel plus some margin for the copyright. So, for the preview, it now only acquires one clipping. The same will apply when actually downloading clippings. The larger clippings will save web service calls and are also more efficient, particularly with respect to the limited contingent associated with an API key.

Please not that if you re-publish any of the map or image clippings, directly or indirectly, with or without your Trainz route, make sure that you adhere to Google and Microsoft terms of service and provide proper copyright notices and other applicable attribution.

That is what we get with the new service, for both Google and Microsoft:



There will be an updated settings xml file, which, of course, will only work for TransDEM 2.6.1



You can also edit the API key settings yourself and you will need to open this editor to enter your Google and/or Microsoft API key:




Some work still needs to be done, fine tuning, more testing, writing a new chapter for the manual and writing the tutorials to obtain an API key. After that is finished, TransDEM 2.6.1 will be released as a downloadable update patch, free of charge to all TransDEM 2.6 users. New or upgrade customers will receive TransDEM 2.6.1 after its release without the need for an extra patch.