|Home | Products | Issue Tracker | FAQ | Download|
Table of Contents
A tileindex is a shapefile that ties together several datasets into a single layer. Therefore, you don’t need to create separate layers for each piece of imagery or each county’s road data; make a tileindex and let MapServer piece the mosaic together on the fly.
Making a tileindex is easy using ‘gdaltindex’ for GDAL data sources (rasters) and ‘ogrtindex’ for OGR data sources (vectors). You just run them, specifying the index file to create and the list of data sources to add to the index.
For example, to make a mosaic of several TIFFs:
gdaltindex imagery.shp imagery/*.tif
And to make a mosaic of vectors:
ogrtindex strees.shp tiger/CA/*.shp tiger/NV/*.shp
ogrtindex and gdaltindex add the specified files to the index. Sometimes you’ll have to delete the index file to avoid creating duplicate entries.
Using a tileindex as a layer is best explained by an example:
LAYER NAME "Roads" STATUS ON TYPE LINE TILEINDEX "tiger/index.shp" TILEITEM "LOCATION" END
There are two items of note here: TILEINDEX and TILEITEM. TILEINDEX is simply the path to the index file, and TILEITEM specifies the field in the shapefile which contains the filenames referenced by the index. The TILEITEM will usually be “LOCATION” unless you specified the -tileindex option when running gdaltindex or ogrtindex.
Two important notes about the pathnames:
- The path to TILEINDEX follows the same conventions as for any other data source, e.g. using the SHAPEPATH or else being relative to the location of the mapfile.
- The filenames specified on the command line to gdaltindex or ogrtindex will be used with the same conventions as well, following the SHAPEPATH or else being relative to the mapfile’s location. I find it very useful to change into the SHAPEPATH directory and then run ogrtindex/gdaltindex from there; this ensures that I specify the correct pathnames.
A tileindex is often a performance boost for two reasons:
- It’s more efficient than having several separate layers.
- MapServer will examine the tileindex to determine which datasets fall into the map’s view, and will open only those datasets. This can result in a great savings for a large dataset, especially for use cases where most of the time only a very small spatial region of the data is being used. (for example, citywide maps with nationwide street imagery)
A tileindex will not help in the case where all/most of the data sources will usually be opened anyway (e.g. street data by county, showing states or larger regions). In that case, it may even result in a decrease in performance, since it may be slower to open 100 files than to open one giant file.
The ideal case for a tileindex is when the most typically requested map areas fall into very few tiles. For example, if you’re showing state and larger regions, try fitting your data into state-sized blocks instead of county-sized blocks; and if you’re showing cities and counties, go for county-sized blocks.
You’ll just have to experiment with it and see what works best for your use cases.