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.
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 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
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.
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
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.
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
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.
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
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.
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.
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
.shpfile. This file is created automatically if it is absent.
The results of other OGC conditions are cached.
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
ILcdRaster implementations use lazy loading to retrieve pixel data. Efficient raster painting is therefore also closely tied to efficient
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
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.
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.
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.
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.