LuciadFusion Release notes

• The outline of the area is now drawn with a solid stroke instead of a dashed stroke
• The hostile indicator ("ENY") is now rendered in the outline stroke, when the symbol's affiliation is set to 'Hostile'

LuciadFusion Studio now supports the Autodesk Revit format.

Adding or crawling a Revit file will result in two data entries: one for the geometry data and one for the features data. The geometry data can be published in an OGC 3D Tiles service. It will be pre-processed into OGC 3D Tiles before the service is started. The features data can be published in a WFS service.

The article Serving BIM data from LuciadFusion Studio explains in more detail how you can use Revit data.

The Spring Boot dependencies of LuciadFusion have been upgraded from version 2.7 to version 3.2. This newer version brings numerous new features and fixes. It's advisable to read through the release notes of every version to know what is new, what has changed and what has been deprecated.

• Spring Boot 3.0 Migration Guide
• Spring Boot 3.1 Release Notes
• Spring Boot 3.2 Release Notes
• Spring Framework 6 Release Notes
• Preparing for Spring Security 6
• Spring Security 6 migration guide

Check out our LuciadFusion troubleshooting guide for a list of major changes caused by the Spring Boot upgrade.

LuciadFusion and LuciadLightspeed users can now visualize ECW images with any number of bands and any bit depth.

TLspRadarVideoLayerBuilder now has the ability to work with radar feeds whose angular or radial resolution are variable over time. This requires the user to manually specify the resolution of the visualization, which is then effectively decoupled from that of the data. The new method displayResolution() on the layer builder is used to enable this behavior. If called, the radar video layer will be fully robust against all variations in the resolution of the incoming data.

Visualization of a Revit file in LuciadRIA, processed and served using LuciadFusion's OGC 3D Tiles service

Added support for the Autodesk Revit data format. Autodesk Revit is a BIM software tool for architects, engineers, and construction professionals to model shapes, structures, and systems in 3D.

For more details, see the Autodesk Revit entry in the Data Formats documentation section

The following new system properties let users configure reference decoder priority for the following model decoders:

• TLcdGeoTIFFModelDecoder : com.luciad.format.raster.TLcdGeoTIFFModelDecoder.referenceDecoderPriority
• TLcdLASModelDecoder : com.luciad.format.las.TLcdLASModelDecoder.referenceDecoderPriority
• TLcdE57ModelDecoder : com.luciad.format.e57.TLcdE57ModelDecoder.referenceDecoderPriority

The priority decides whether the model reference decoding is first attempted from the reference information embedded in the data file and then fall back to external reference source files such as WKT (.prj), REF (.ref) and EPSG (*.epsg) in case of an error or vice versa when the other reference decoder priority is selected.

For more information on how to configure the reference decoder priority for supported ILcdModelDecoder implementations, refer to the following article: Setting model reference decoder priority

To ease using HTTP/2 with LuciadFusion, the following improvements have been introduced:

• A new article How to use HTTP/2 with LuciadFusion has been introduced.
• HTTP/2 is now enabled by default in the LuciadFusion Platform configuration.
• In order to enable HTTP/2 with the sample Jetty server shipped with LuciadFusion, we have included the following sample dependencies:

A LuciadFusion Studio REST API developer can now define custom properties with a limited set of allowed values for the Long data type in addition to the already supported String type. As a result of this:
addLongProperty(String, Set) and addLongProperty(String, String, Set, boolean) methods have been added to the class TLfnCustomPropertyDefinitions.
In addition to the above inclusions to the API, the following addEnumProperty(String, String, Set, boolean) and addEnumProperty(String, Set) methods of the class TLfnCustomPropertyDefinitions have been deprecated in favor of new methods addStringProperty(String, String, Set, boolean) and addStringProperty(String, Set).
It is recommended to use the newly introduced methods instead of the deprecated ones. The deprecated methods will subsequently be removed in one of the future product releases.

As a result of this enhancement the LuciadFusion Studio REST API endpoints GET /api/data/custom-properties and GET /api/data/queryable-propertiesno longer return 'Enum' as a 'type' in a REST API response. They now return the data type as determined by the type of value a custom property can take i.e. Long, Double, Boolean, Date, String. This change is consistent with the behavior of the custom properties which already returned the 'type' as their data type of the values.

A new style class, TLcdMilitarySymbolStyle, has been added to the Military Symbology API. This class can be used to define the symbol style of both APP-6 and MIL-STD-2525 symbols.

The usage is equivalent to the usage of the existing, standard specific style classes (TLcdDefaultAPP6AStyle and TLcdDefaultMS2525bStyle). You can configure a symbol dependent style, by either having your domain objects implement ILcdStyledMilitarySymbol or by defining a default style on your painter providers or layers.

The following methods have been added to configure a TLcdMilitarySymbolStyle on painter providers and layers:

• TLcdAPP6AGXYPainterProvider.setDefaultMilitarySymbolStyle
• TLcdAPP6AGXYLabelPainterProvider.setDefaultMilitarySymbolStyle
• TLspAPP6ALayerBuilder.defaultStyle
• TLspAPP6ASymbolStyle.Builder.militarySymbolStyle
• TLcdMS2525bGXYLabelProvider.setDefaultMilitarySymbolStyle
• TLcdMS2525bGXYLabelPainterProvider.setDefaultMilitarySymbolStyle
• TLspMS2525bLayerBuilder.defaultStyle
• TLspMS2525bSymbolStyle.Builder.militarySymbolStyle
• TLspMilitarySymbologyLayerBuilder.defaultStyle

We now enable support for vertical datums by default for a number of model decoders. If your services require preprocessing (such as LTS and OGC 3D Tiles) and you encounter issues with vertical datum application, you may need to preprocess the involved data again to ensure correct application of the vertical datum support. Preprocessing again is only necessary if you have other data with vertical datums and observe inconsistencies. Inconsistencies occur when combining the following data:

• Data which is served by an LTS or OGC 3D Tiles service, which has not applied the vertical datum. This usually occurs because the service was created with an older LuciadFusion version (2023.1 or older), which did not enable vertical datum support by default.
• Data which is loaded directly into a client application, is served by a service which does not do preprocessing or is served by a new LTS or OGC 3D Tiles service, which has been created in LuciadFusion 2024.0.

More information about enabling support for vertical datums by default is given in the release note for issue LCD-12921.

• The colon ":" is no longer accepted in Windows file names.
• Spaces are no longer accepted in file URI's. They need to be escaped as described in the URI specification.

The default behavior of a number of model decoders has been changed. We now enable support for vertical datums by default for a number of model decoders. The vertical datum support will cause the appropriate geoid height to be applied to data files of the affected formats, if the data advertises a vertical datum. In previous versions, we ignored the vertical datum advertised by data by default.

Using the geoid will result in the use of more accurate elevation values, at the cost of performance when processing the data.

The following data formats are affected by this change:

1. DEM: TLcdDEMModelDecoder
2. DMED/DTED: TLcdDMEDModelDecoder, TLcdDTEDModelDecoder, TLcdDTEDDirectoryModelDecoder
3. ETOPO: TLcdETOPOModelDecoder
4. GeoTIFF: TLcdGeoTIFFModelDecoder
5. LAS/LAZ: TLcdLASModelDecoder
6. SwissDHM: TLcdSwissDHMMatrixModelDecoder

Because the default behavior has changed for these formats, your data may be painted at a different height, which can cause misalignment with your other layers. For example, you may apply the geoid to points in a LAS file, which causes your LAS points to be painted at a different elevation. If you combine this LAS data with an inaccurate terrain layer, there may be overlap between your LAS points and the terrain layer. You should check that your data is still properly aligned with your other layers after upgrading.

The recommended way to fix such alignment issues is to make sure you use an accurate terrain layer and use the same geoid on all your layers with elevation data. You should also verify that all your elevation data advertises the correct vertical datum. Read our article on Detecting and fixing vertical datum issues for more details.

If you have different behavior then before, and you are sure that the old behavior is preferred, you can revert to the old behavior in the following ways:

• Disable geoid support for a specific model decoder, by calling the method #setSupportGeoidDatums(boolean)
• Disable geoid support for all aforementioned model decoders, by setting the system property com.luciad.geodesy.geoidSupport.LEGACY to true.

Since the upgrade to Spring Security version 6, Spring Security blocks all requests for which no authorization rule is defined. In order to register authorization rules for services in LuciadFusion, a few changes have been made in the LuciadFusion configuration and the ILfnServiceTypeConfiguration interface, which makes it possible to plug in custom service types in LuciadFusion

The documentation changes consist of 2 new properties: fusion.security.serviceAuthenticationRequired and fusion.security.authenticatedEndpoints

• fusion.security.serviceAuthenticationRequired allows you to globally configure if services published in LuciadFusion require authentication or if anonymous access is permitted.
• fusion.security.authenticatedEndpoints allows you to override the configuration set by fusion.security.serviceAuthenticationRequired for certain url patterns. This can, for example, be used if you want to allow anonymous access for all services except services of a certain type (wms, wfs, lts, etc)

Additionally we have deprecated the property fusion.accessControl.authenticatedEndpoints. This property used to only have an effect when access control is enabled, it is now replaced by fusion.security.authenticatedEndpoints, which is also active when access control is disabled. If you are using fusion.accessControl.authenticatedEndpoints, this configuration will still be applied, but this property will be removed in a future LuciadFusion release, so we recommend that you replace its usage by fusion.accessControl.authenticatedEndpoints.

We have added the method getEndpointPatterns() to he interface ILfnServiceTypeConfiguration. This method is used to inform the LuciadFusion Security system of which url patterns are handled by the service type implementation.

Please read the following articles for more information:

• How to configure access to services in LuciadFusion
• Configuring access to your endpoint handlers

The LuciadLightspeed and LuciadFusion APIs now use the Jakarta EE 10 API and Jakarta Servlet 6.0 API, where in previous releases the Java EE 7 API and Java Servlet 3.1 API were used. There are a few breaking changes in the new Jakarta Servlet 6.0 API, the main one being a rename of the javax.servlet package to jakarta.servlet. Any LuciadLightspeed or LuciadFusion API that use classes from this package thus contain a corresponding breaking change. The affected classes are mainly the classes implementing the OGC server standards (WM(T)S, WFS, etc). Any compilation errors you encounter related to this change can typically be resolved by performing a find and replace operation.

Refer to the documentation on hardware and software requirements in the prerequisites section for more information.

The class TLcdECWConfiguration is now removed from the API to keep the API clean and simple. If you were using this class, it is now required to use TLcdECWModelDecoder#getMaxCacheSize and TLcdECWModelDecoder#setMaxCacheSizeinstead of similar methods exposed by TLcdECWConfiguration.

The class TLcdECWImageDecoder is now removed from the API due to its limited capability in supporting decoding of multi band and multi bit depth ECW data files. If you were using this class, it is now required to use the enhanced TLcdECWModelDecoder, which fully supports decoding multi band and multi bit depth ECW data files. This updated decoder provides a more robust and versatile solution for handling ECW data.

The previous libecw-6.1.*.jar libraries are now replaced by ecw-6.1.0-native*.jar containing the native libraries provided as part of ERDAS ECW JP2 SDK 6.1.0. This change also adds the ecw-6.1.0.jar library which contains the JNI bindings to access the functionalities exposed by the packaged native libraries.

The geometry type of a number of APP-6A/B Minefield symbols has been changed. These symbols were modeled as polygons, which required the symbol to have at least 3 anchor points to define the symbol's shape. To better align these symbols with the NVG geometry bindings specification, the geometry has now been changed to a point, which requires only a single anchor point to define the symbol's shape. The following symbols are affected by this change:

• 2.X.2.2.1.6.1 "Planned Minefield"
• 2.X.2.2.1.6.2 "Completed Minefield"
• 2.X.2.2.1.6.5 "Antitank (AT) Minefield"
• 2.X.2.2.1.6.6 "Scatterable Mines"
• 2.X.2.2.1.6.7 "Antipersonnel (AP) Minefield Reinforced With Scatterable With Self-Destruct Date-Time-Group"
• 2.X.2.2.1.6.8 "Scatterable Minefield (Antitank Mines) With Self-Destruct Date-Time-Group"
• 2.X.2.2.1.7 "Executed Volcano Minefield"

The interfaces ILcdAPP6AStyle and ILcdMS2525bStyle, and their implementations TLcdDefaultAPP6AStyle and TLcdDefaultMS2525bStyle have been deprecated.

If you need to create a symbol style, you should use the newly introduced class TLcdMilitarySymbolStyle.

The discoverDataSources method of the TLcdBinzModelDecoder now returns a list containing two TLcdBIMDataSource objects: one for the geometry model, and one for the features model. Previously, it returned a list containing only a TLcdDataSource for the geometry model.

The following snippet can be used to get the geometry model for both the new and the previous version of this discoverDataSources method.

      TLcdBinzModelDecoder decoder = new TLcdBinzModelDecoder();
      List<? extends ILcdDataSource> dataSources = decoder.discoverDataSources("path/to/dataset.binz");
      ILcdModel geometryModel = decoder.decodeSource(dataSources.get(0));
    

The following deprecated DGN classes have been removed from the LuciadLightspeed API:

• TLcdDGNMicroStationServlet
• TLcdDGNMicroStationModelDecoder
• TLcdDGNMicroStationDisplayInfo
• TLcdDGNMicroStationLevelSymbology

Any usage of these classes should be replaced by the TLcdDGNModelDecoder.