These performance guidelines apply to LuciadLightspeed applications in general, no matter what view type you are using. They are related to model selection and querying, and the painting of raster data.

There are other performance measures you can take, but those are specific to either Lightspeed views or GXY views. To read more about improving performance in Lightspeed views or GXY views, see the Lightspeed view performance guidelines or the GXY view performance guidelines respectively.

Selecting models for tiled data

LuciadLightspeed provides several implementations of the ILcdModel interface. Which implementation to choose depends on the type of operation that you typically perform on the model data. See the introduction to models for more information. Next to the main implementations of ILcdModel, you can also use two implementations for tiled data as described below.

TLcd2DRegularTiledBoundsIndexedModel

Like the TLcd2DBoundsIndexedModel, the TLcd2DRegularTiledBoundsIndexedModel maintains an internal spatial data structure that allows you to quickly retrieve domain objects based on their bounds. In this case, the data structure is a regular grid. It provides an efficient implementation of the ILcd2DBoundsIndexedModel interface with its applyOnInteract2DBounds method. In addition, the class also implements the ILcdIntegerIndexedModel interface.

Because of its regular tiling, this class is more suited for elements that are fairly evenly distributed inside the model bounds. The simplicity of the data structure is also best suited to elements that change position frequently.

TLcdRegularTiled2DBoundsIndexedModel

The TLcdRegularTiled2DBoundsIndexedModel is mainly intended for the lazy loading of large data sets. A data set must be organized as a regular grid, with each tile in the grid corresponding to a file. You must still implement the ILcdTileProvider that provides the individual tiles.

Querying a model

When you query a model using the ILcdModel#query method with a query containing an ILcdOGCCondition, the performance of this method depends heavily on the type of condition, the model implementation, and the backend of the model.

That performance becomes highly relevant when you are trying to visualize large vector data sets. See Dealing with large vector data sets for more information.

In-memory models

In-memory models are usually based on TLcd2DBoundsIndexedModel. Many file formats, such as GML or GeoJSON, are based on TLcd2DBoundsIndexedModel, and load the entire file into memory.

Its query() method will use applyOnInteract2DBounds() to first find the elements within the requested spatial extent, and then apply the OGC condition on each of those.

This is also the default behavior for all ILcd2DBoundsIndexedModels.

If a model is not spatially indexed, the query() method will use elements() to loop over all objects and apply the OGC condition on each of them.

Databases

LuciadLightspeed models for databases convert the OGC condition into a SQL statement. The SQL statement will contain a bounding box combined with other restrictions: s

Program: Example SQL select statement which combines spatial and non-spatial filtering
SELECT ST_AsEWKB(geometry), id, name
  FROM osm_roads
  WHERE (geometry && ST_SetSRID('BOX3D(4.6187 50.7863,4.8134 50.9403)'::box3d,4326))
         AND (type = 'motorway')

The performance depends heavily on the configuration of the database. Make sure to have the appropriate indices on your data. You will certainly need a spatial index. In the example above, an index on "type" would be beneficial as well.

This performance not applies to Oracle, Microsoft SQL Server, PostgreSQL, and GeoPackage.

WFS servers

The client model for a WFS server simply sends the OGC condition to the server as XML.

The WFS server then delegates that OGC condition to its back-end models.

Therefore, the performance depends mostly on the back-end model implementation.

SHP models

Models for Shapefiles are of the lazy-loading type. They have been optimized to accelerate query() calls with OGC conditions:

  • The spatial extent (if any) is evaluated by means of a spatial index file next to the .shp file. This file is created automatically if it is absent.

  • The results of other OGC conditions are cached.

Raster painting

Painting raster data efficiently is challenging because raster data sets are generally large. This section focuses on optimizing the performance of the raster painters in LuciadLightspeed. Most standard ALcdImage and ILcdRaster implementations use lazy loading to retrieve pixel data. Efficient raster painting is therefore also closely tied to efficient data loading.

Using tiled raster data

When painting raster data, the LuciadLightspeed raster decoders use the tiled structure of the raster to load only the tiles that are required. Many formats are always tiled (for example, DMED, DTED, DEM). Some formats may be tiled (such as GeoTIFF) and other formats are never tiled (notably JPEG). Non-tiled data negatively affects decoding time, memory usage, and therefore ultimately, painting performance.

The GeoTIFF format provides a flexible way to tile images inside a single file, while still allowing different color schemes (8-bits with color map, 24-bits true color,…​) and encoding schemes (ZIP, LZW, JPEG,…​). The TLcdGeoTIFFModelDecoder and TLcdGeoTIFFModelEncoder support such tiled GeoTIFF images. The GeoTIFF raster encoding sample Converter provides a simple conversion tool for reading raster data in any supported format and writing them out as tiled GeoTIFFs. Typical tile sizes are 256x256 or 512x512 pixels.

Note that the freely available libtiff library contains a command-line tool tiffinfo that allows you to inspect the structure and encoding of GeoTIFF files. This is a good starting point for checking how efficient your GeoTIFF raster data will be in your application.

Using multilevel raster data

The presence of large raster data can still slow down raster painting, in spite of any tiling. Especially if the view is zoomed out, a large amount of data may be visible. Creating data with multiple levels of detail then provides a major performance improvement. When the view is zoomed out, the painters select lower levels of detail, thus loading less data and painting more rapidly. The typical formats that offer multiple levels of detail are the wavelet formats JPEG2000, ECW, and MrSID.

The GeoTIFF format provides an alternative, as it can store multiple images at different resolutions in a single file. A benefit over the wavelet formats is that it does not require any native libraries. The TLcdGeoTIFFModelDecoder and the TLcdGeoTIFFModelEncoder support such multilevel (and tiled) GeoTIFF images. The GeoTIFF raster encoding sample Converter provides a simple conversion tool. A multilevel raster should typically contain 3, 4, or more levels, depending on the expected scale range of the application.

Tuning DMED/DTED fall-back

If you are working with DMED/DTED files, the TLcdDMEDModelDecoder and the TLcdDTEDDirectoryModelDecoder provide some specific settings that allow to fall back on lower or higher DTED levels in case not all DTED levels are available. Enabling fall-back on higher levels ensures that some elevation data is always visible, for example in case DTED level 1 is available but DTED level 0 is not. However, such a setup generally performs badly, since each level that is actually loaded is much larger than the preceding level that is missing. The best solution is to ensure that low levels are always available. For example, DTED level 0 data can easily be downloaded and installed in the DTED directory structure. In general, it helps to inform the model decoders of the minimum and maximum levels that are available, using the corresponding setters.

Combining raster data

Raster objects are typically put in models, just like other model elements. This means that they are painted and processed sequentially, just like any other model elements. If many raster objects have to be warped, this causes a large overhead, since a warped image is computed for each raster in turn. Applications should therefore try to avoid creating models with many individual raster objects, for example from individual DTED files. If the raster objects lie in a regular grid pattern, it is much more efficient to group their tiles into a single raster, as is done when reading DTED files based on a DMED file for example.