Knowledge Base

For best performance, please consider the following guidelines:

1. In situations involving huge vector layers, extract the major roads, or any other major features, to a separate layer(s). This offers the possibility, by turning layers on/off, of presenting large area general map views only from the general layer, without the overhead of parsing the entire detailed data set from original layer.
2. Ensure 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. Avoid using LIKE whenever possible.
5. Perform queries against numeric fields (not text fields) whenever possible. This is of particular importance with the DK.NET edition.
6. 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 R-tree will deliver performance in all situations at least as good as without R-tree 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 the layer was opened, 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.
7. Consider using the Smart Size feature to avoid consumption of computational resources to render vector map features features that are too small at a given zoom/scale level to be meaningfully visible. For more about the Smart Size feature, refer to KB10711.
8. Turn off IncrementalPaint feature for layers in which this is not necessary, particularly raster image layer
     [TatukGIS Layer1]
  IncrementalPaint=False
   For more about Incremental Paint, refer to KB10540.
9. Move vector layers to an SQL database in situations involving i) working with huge vector layers (hundreds of MB’s) at close zoom levels and ii) attribute querying with huge vector layers. Examples might be a query for a specific river or an optimal route, or querying for an object based on an attribute, within a very large vector file. In these situations, converting the layer to, for example, an SQL layer on the free SQLite database can deliver significant speed improvements.
   Keep in mind, however, that SQL layers are 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. This is because simultaneously fetching thousands of records from the database is not efficient.
10. Consider converting any very large image layers to a TatukGIS PixelStore format image layer. PixelStore can be much faster than other image formats because PixelStore seamlessly organizes the image data as tiles held in an SQL database.