KB10391 - Please offer any guidelines on how to most efficiently organize my map data in a TatukGIS project. My application includes both vector and image layers and involves custom rendering?

For best performance, please consider the following guidelines:

1) In situations involving huge vector layers, extract the major roads, or any other major features, etc., to a separate layer(s). This offers the possibility, by turning the full layer on/off, of presenting general map views of large areas from only the general layer, without the overhead of parsing the entire detailed data set from original layer.

2) Ensure that Query definitions have no syntax errors.

3) Use braces in the Query definitions. For example, instead of using:

   query=rd_class ='Motor' or rd_class like 'SH%'

   Use:

   query=(rd_class ='Motor') or (rd_class like 'SH%')

4) When applicable, split queries into multiple sections for greater efficiency. Therefore, instead of using:

    [TatukGIS Layer1 1]
    query=(d_class ='Motor')or (d_class like 'SH%')
     …

try using:

    [TatukGIS Layer1 1]
   query=rd_class ='Motor'
     …
     [TatukGIS Layer1 2]
    query= rd_class like 'SH%'
     …

5) Avoid using LIKE whenever possible.

6) Perform queries against numeric fields (not text fields) whenever possible. This is of particular importance with the DK.NET edition.

7) Enable R-tree indexing support for faster performance at closer zoom levels with shape files. Generally, based on the way that the DK is designed, using it will offer performance in all situations that is at least as good as without it enabled, and much better performance at closer zoom levels. But remember that a layer can be slow to open the first time with R-tree enabled, or if the R-tree index was not saved the previous time, because the R-tree index must be constructed. (R-tree is not important for SQL layers.) For more information about the R-tree feature, refer to KB10279.

8) Consider the use of the Smart Size feature to aviod the use of computational resources to render vector map features features that are too small at a given zoom/scale level to be meaningful to the map view anyway. For more about the Smart Size feature, refer to KB10711.

9) Turn off IncrementalPaint for layers for layers which this is not necessary, particularly raster image layers:

    [TatukGIS Layer1]
    IncrementalPaint=False
   …

For more about Incremental Paint, refer to KB10540.

10) Move vector layers to an SQL database in situations involving i) working with huge vector layers (hundreds of MB’s) at relative close zoom levels and ii) attribute querying with huge vector layers. Examples would be querying for a specific river or an optimal route, or just querying for an object based on an attribute, within a very large vector file. In these situations, even moving the layer to MDB (free Microsoft JET Engine, MS Access) can offer significant speed improvements.

But keep in mind that the use of SQL layers will be slower than a standard vector shapefile when panning or zooming when fully or mostly zoomed out to the full extent of a large vector coverage. The situation is simply that simultaneiously fetching thousands of record from the database is not efficient.

11) With very large raster image data sets, consider converting the image data into a single TatukGIS PixelStore format image layer. PixelStore can be much faster than other image formats because PixelStore seamlessly (invisibly) organizes the image data as tiles that are held in an SQL database.