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’sSoftReference
mechanism. -
WEAK_REFERENCED
: Identical to SOFT_REFERENCED, but data is kept in memory through Java’sWeakReference
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 |
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.
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).
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 |