To test it out, I tried tiling a sample GeoTIFF file from the Ordnance Survey Street View dataset. The option I was particularly interested in is the “Resampling” parameter, since I wasn’t particularly satisfied with the results that I was obtaining from MapTiler. Web viewer to generate (all,google,openlayers,none) -default ‘all’ Options for generated HTML viewers a la Google Maps u URL, –url=URL URL address where the generated tiles are going to be published n, –no-kml Avoid automatic generation of KML files for EPSG:4326 For a dataset with different projection use with caution! k, –force-kml Generate KML for Google Earth – default for ‘geodetic’ profile and ‘raster’ in EPSG:4326. Options for generated Google Earth SuperOverlay metadata v, –verbose Print status messages to stdout NODATA transparency value to assign to the input data z ZOOM, –zoom=ZOOM Zoom levels to render (format:’2-5′ or ’10’). s SRS, –s_srs=SRS The spatial reference system used for the source input data Resampling method (average,near,bilinear,cubic,cubicspline,lanczos,antialias) – default ‘average’ Tile cutting profile (mercator,geodetic,raster) -default ‘mercator’ (Google Maps compatible)
h, –help show this help message and exit –version show program’s version number and exit The syntax and list of possible parameters can be retrieved by opening up a command shell and calling: With these two in place, you can get on with calling the script. (If you don’t have the GDAL library itself installed, you can add this from the OSGEO4W installer as well).
I don’t know much about python, so I won’t even attempt to explain this further, other than to say that the easiest fix is to install the requisite libraries from the OSGEO4W package, highlighted as follows: The reason is that, in addition to the GDAL library itself, you also need to install the python bindings for GDAL – allowing you to call into the GDAL functions from a python script. If you attempt to run the GDAL2Tiles.py script straight out of a newly compiled GDAL build, for example, you’ll most likely get the “No module named gdal” errors, as follows: Setting up GDAL2TilesĪlthough GDAL2Tiles.py comes bundled with GDAL library, it has dependencies on other libraries. To correct those issues, you’re going to have to ditch the pretty MapTiler front-end and get dirty with the command-line instead, manually running the GDAL2Tiles.py script that sits at the heart of MapTiler.
Secondly, the front-end MapTiler interface does not expose all of the possible parameters of the underlying script.Reading through the release notes on the GDAL site shows several bug fixes and enhancements have been introduced to the GDAL2Tiles.py script between these two versions. However, the GDAL2Tiles.py script maintained as part of the GDAL library, and packaged with the latest GDAL 1.8.1RC2release, is version 19288, dated April 2010.
Generally speaking, the application is reliable, easy-to-use, and generates pretty good quality results. This is an admirable objective in itself because, as noted in previous posts, simply trying to compile the components of a typical spatial tool chain can be quite a headache. Like all GUI wrappers, it provides a convenient front-end interface, and doesn’t require the end user to have any knowledge of command-line processing or build tools. MapTiler is essentially just a GUI wrapper around the GDAL2Tiles.py python script, which is distributed as part of GDAL.
MapTiler is a Windows application that will reproject and cut any GDAL-supported datasource into a set of 256px x 256px image tiles, suitable for use as a custom tile layer in Google Maps or Bing Maps et al. So I’ve been using MapTiler to create some quick raster tilesets from a set of GeoTIFF images.