About this release
The 2025.0 release of LuciadFusion supports serving NITF data as a non-georeferenced intelligence report. User feedback was used as input for a number of usability improvements to the OGC WMS and WFS services. Finally, the support for BIM and CAD data was improved as well.
This document lists the most noteworthy improvements. You can find the full list of changes in the release notes.

Benefits of the new features
Publish NITF data (for viewing in the browser)
Decoding NITF data is a long-standing feature of our products LuciadLightspeed and LuciadFusion. This release of LuciadFusion brings a set of important upgrades to the NITF support.
A collection of improvements based on user feedback
We acted on collected feedback and improved the handling of images and vector overlays, while respecting the paint order of the different elements. These improvements also led to the introduction of a new third-party library, libjpeg-turbo, to decode JPEG images and the removal of a class and some methods from the API because they were never intended for direct use and caused some confusion.
Serving NITF data as geo-referenced or non-georeferenced data set
Recently, we noticed an emerging need for the display of intelligence information in the browser. This release of LuciadFusion, as well as the new release of our browser-based product LuciadRIA, allows us to satisfy this use case.
The NITF decoder now supports the use of NITF information in a non-georeferenced view. This capability enables you to retrieve
the data in pixel coordinates. With this aim, TLcdNITFModelDecoder.discoverDataSources
now offers two data sources.
You can use the first data source to decode the NITF data into a georeferenced model, similar to the data source returned in the past. The resulting model can be used to visualize the data in a georeferenced view. The benefit of this approach is that it shows the data in context, combined with other data you may have of the same area.
You can use the second data source to decode the NITF data into a non-georeferenced model. To allow for fine-grained inspection
of all annotations, this non-georeferenced model is an ILcdModelTreeNode
with a sub-model for each NITF data segment. You can then publish these non-georeferenced data items with a pixel coordinate
model reference (CRS:1) as an OGC WMS service in LuciadFusion.
LuciadFusion now supports this second scenario end-to-end. As illustrated in Figure 2, “When crawling an NITF data set, LuciadFusion creates two data sources, as illustrated in LuciadFusion Studio”, crawled NITF data ends up in LuciadFusion as two data sources:
-
A georeferenced data source with the native geographic reference of the data
-
A non-georeferenced data source with a cartesian reference (pixel coordinate model)
Afterward, you can flexibly decide how to publish NITF data: as a georeferenced WM(T)S layer, as a cartesian CRS:1 WMS layer, or as both.

Furthermore, a new LuciadFusion configuration flag wms.layerPerProduct
in the fusion.common.yml
configuration file provides additional flexibility for publishing WMS layers. By default, it is enabled, meaning that a LuciadFusion
product with one or more data items is mapped to a single WMS layer. This is the same behavior as in past releases.
If you disable it, LuciadFusion creates a WMS layer for each model available in the product. If the model is a model tree,
the WMS layer gets created for each sub-model.
The NITF non-georeferenced data source with cartesian CRS:1 reference mentioned above is a model tree, with a model per segment.
Therefore, if you disable the wms.layerPerProduct
setting, the resulting service offers a WMS layer per NITF segment. This mapping allows clients to switch individual NITF
segments on and off while inspecting the data.
Sample code/documentation to get you started
We refer to the existing NITF documentation for more information on how to integrate this format: Data Formats: NITF/NSIF. For details about the new third-party library and slight API modifications, see the release notes.
To help you set up a non-georeferenced WMS, the article How to set up a non-georeferenced WMS was added to the documentation.
Improvements to the configuration of OGC Web Services
We implemented some usability improvements to the OGC services. This section lists them per service type in no particular order.
OGC WMS
-
A new configuration property allows users to refine the mapping of LuciadFusion products and the data items within these products to WMS layers. By default, each product in a WMS service is mapped to a single WMS layer. An example use case for a more refined mapping is the publication of each NITF segment in a product as a WMS layer, as discussed in Serving NITF data as geo-referenced or non-georeferenced data set.
-
The constructor of
TLcdWMSGeoJsonGetFeatureInfoEncoder
now accepts a parameter that indicates whether to use the name of a property or its display name as the key for the feature information properties.
OGC WFS
-
You can now configure the WFS feature type title and names used by your WFS services. We introduced new REST API endpoints and UI in the LuciadFusion Studio web app that allow you to define user-friendly feature type names. The article How to configure the WFS feature types offers more detail.
-
The WFS server’s capability to output features as GeoJSON has been made more robust: an unsupported geometry type is now automatically transformed to a geometry type supported in GeoJSON, such as points, lines, polygons and collections of them. This improves the access to CAD data such as DGN and DWG files through a WFS server, for example.
OGC 3D Tiles
LuciadFusion can now also generate OGC 3D Tiles 1.1 services for datasets with a 'Mesh' data category, such as BIM, OBJ and GLB datasets. This capability is offered both via the REST API and via the LuciadFusion Studio web app UI. Also, OGC 3D Tiles 1.0 and 1.1 mesh datasets can now be re-processed to change the version or compression type.

Improvements to the LuciadFusion platform
More flexible security configuration
You can configure access to service endpoints in several ways. This release adds the possibility to dynamically configure
whether authenticated access is required on a service-by-service basis, using the service detail panel in the LuciadFusion
Studio web application or the PUT /api/services/{serviceId}
endpoint. We refer to the updated article How to configure access to services in LuciadFusion for more details.
Faster querying by custom metadata properties
The storage of custom metadata properties has been optimized. For very large amounts of metadata records, this results in a significant improvement in query speed.
Updated platform requirements
In alignment with the end of support for Windows 8.1 and Windows Server 2012 by Microsoft, and the end of support for macOS 12 by Apple, we are updating our platform support. LuciadFusion is now supported for development and deployment on:
-
Windows, starting from Windows 10 and Windows Server 2016
-
macOS, starting from macOS 13
Other improvements
- DWG improvements
-
DWG files served using LuciadFusion now support multi-line text. This means that you can use the
TEXT
andMTEXT
entities in your DWG files to display text that spans multiple lines. In addition, we added support for extraMTEXT
directives. - BIM data types alignment
-
Metadata handling has been unified across all BIM formats. This means that BIM, IFC, and Navisworks models now expose metadata the same way, using
metadata
andmetadataGroup
properties. This alignment makes it easier to work with BIM data in LuciadFusion, because you can use the same approach for all formats. - Guidance with converting data in the Filmbox (FBX) file format
-
The Filmbox (FBX) file format is a proprietary 3D file format developed by Autodesk. This release of LuciadFusion features an article that shows how you can convert an FBX file to OGC 3D Tiles. The article is titled Handling FBX data.
- Linux ARM 64-bit support for selected data formats
-
LuciadFusion now supports a Linux ARM 64-bit architecture for a selected list of data formats using native dependencies. Data can now be crawled, decoded, and published by a LuciadFusion instance running on a Linux ARM 64-bit machine. We refer to the release notes for an overview of the supported formats.
- 3D Tiles Processing Engine performance improvement
-
The 3D Tiles Processing Engine that processes 3D meshes into 3D Tiles has been optimized, resulting in less memory usage and faster processing.