This guide offers several tips and guidelines that allow you to speed up your application by optimizing the decoding and the visualization of ECDIS data.

Enable SENC caching

System ENC (SENC) is a LuciadLightspeed-specific format for representing S-57 data. While the S-57 standard is optimized for exchange purposes, the SENC format is optimized for performance during decoding and visualization.

If SENC decoding is active, and an S-57 catalogue is decoded for the first time, the decoder will convert the catalogue into SENC on-the-fly and store the SENC in a local cache folder. The next time that the catalogue is decoded, it will be decoded from the SENC cache, rather than from the original S-57 source. SENC is typically much faster to load than S-57. The effect of enabling a SENC cache is that the first decoding of an S-57 catalogue will be slightly slower, due to the conversion to SENC, but all subsequent decodings will be significantly faster.

To activate SENC decoding, you have to enable SENC caching. SENC caching is disabled by default. To enable it, use the setUseSENCCache(boolean) on TLcdS57UnifiedModelDecoder or TLcdS57CatalogueModelDecoder. You can configure the SENC cache directory via setSENCCacheDir(File). SENC caches are not thread-safe: make sure that a SENC cache is used by just one decoder instance.

On clients the caching is mostly useful if the data is on a slow network disk for example, but be sure to measure before you enable it in production. On a back-end server, it can be useful for an OGC WMS server. There’s typically no need to activate it for an OGC WMTS server though, as it will cache requests anyway.

Choose the right loading policy for the S-57 catalogue model decoder

The size of S-57 catalogues can range from a few to up to hundreds of ENC cells. In the latter case, it is often impossible to load all data at once, either because the decoding takes too long or because the data does not fit into memory. The TLcdS57CatalogueModelDecoder therefore provides a flexible loading policy. It allows you to control when the data is loaded and how long it needs to be kept in memory.

The decoder provides three loading policies, defined in the TLcdS57CatalogueModelDecoder.LoadingPolicy enumeration:

  • STRONG_REFERENCED: all ENC cells are loaded at once when the catalogue is decoded, and are kept in memory permanently.

  • SOFT_REFERENCED: ENC cells are only loaded when they are first needed, that is, when the model is queried for a region overlapping with the cell’s border. Data is kept in memory through Java’s SoftReference mechanism.

  • WEAK_REFERENCED: Identical to SOFT_REFERENCED, but data is kept in memory through Java’s WeakReference mechanism.

You can configure the loading policy on the TLcdS57CatalogueModelDecoder using the setLoadingPolicy method. By default, it is configured to use the STRONG_REFERENCED policy. When the catalogue model decoder is constructed using the TLcdS57ProductConfiguration.createCatalogueModelDecoder, the loading policy is automatically set to WEAK_REFERENCED.

Use the following guidelines to choose the most suitable loading policy: * Typically, SOFT_REFERENCED is the all-round best choice. It allows for caching cells without overloading the Java heap. * If you experience high memory pressure in your application, you can use the WEAK_REFERENCED policy. * If you have a relatively small dataset and want consistent performance, you can use the STRONG_REFERENCED policy.

The TLcdS57UnifiedModelDecoder does not allow setting a loading policy, but is optimized for the regular display of S-57 data, using the SOFT_REFERENCED policy.

Avoid the ILcdModel.elements() method in catalogues

As S-57 catalogues may be very large, and are often loaded on-the-fly to reduce memory usage, calling elements() on catalogue models is strongly discouraged. It will trigger the loading of all individual S-57 files in the catalogue, which may take several minutes to hours, depending on the catalogue size, the decoder’s loading policy and the performance of the computer system. Instead, try using applyOnInteract() whenever possible, with a bounds argument that is as small as possible.

Filter unused object classes

TLcdS57ModelDecoder and TLcdS57CatalogueModelDecoder provide methods for restricting which object classes are decoded:

  • setObjectClassSelection(int[]) specifies which object classes should be decoded.

  • setExcludedObjectClasses(int[]) specifies which object classes should not be decoded.

You can either set the object class selection or the excluded object classes, but not both.

If you have not set either, the decoder will decode all object classes. This is the default behavior.

You can download the object class codes for ENC from the IHO’s website. The object class codes are listed in a component document of the S-57 IHO Transfer Standard for Digital Hydrographic Data. The document is called "Appendix A - Chapter 1 Object Catalogue".

As an alternative, you can also configure an ILcdFilter on the layer, to control which object to show.

The following table compares the advantages of filtering at the decoder level versus filtering at the layer level.

Table 1. Comparison of filtering at decoder level versus layer level

Filtering at decoder level

Filtering at layer level

Model-view consistency

Model and view contain same elements

Model may contain more elements than shown in view

Model memory usage

Can be reduced by filtering more object classes

Does not change

Flexibility

You can only filter on object class codes

You can implement arbitrary filters, an attribute-based filter for example

Filter modification

Not possible after decoding

Anytime

The S-52 display settings offer another alternative for filtering, with S-52 specific filtering settings. For more information, see the S-52 display settings documentation.

Do not filter the M_COVR object class

The TLcdS52GXYCatalogueLayer uses objects of the M_COVR object class to accelerate rendering performance. It is therefore discouraged to filter this object class at decoder level. You can still filter the class at layer level, as this will not affect performance. The M_COVR class is a metadata object class, and is not displayed by default.

Use correct layer scales

The TLcdS52DisplaySettings allows you to configure scale ranges. Scale ranges are used in GXY and Lightspeed views to determine which navigational purpose level should be displayed at a given map scale. Failing to set reasonable scale ranges might reduce performance significantly: if the lower limit of the scale range for a given level is too small, the level of detail on the map will be too high. Too many cells will be visible on the map, and the catalogue will need to load all these cells to paint its data. The larger the scale ranges, the less data will be visible on the map for a given scale, and the better performance will be. Table 2, “Suggested scale ranges for US ENC data” shows the level scale ranges as suggested by the US National Oceanic and Atmospheric Administration (NOAA).

Table 2. Suggested scale ranges for US ENC data
Level Navigational purpose Scale

1

Overview

1:1,500,001 or smaller

2

General

1:600,001 - 1:1,500,000

3

Coastal

1:150,001 - 1:600,000

4

Approach

1:50,001 - 1:150,000

5

Harbour

1:50,000 or larger