LuciadFusion Release notes

The coordinates in the GeoJSON output of the bim.converter.[bat|sh] commandline sample are now 2D coordinates again instead of 3D coordinates with a zero altitude. This is more in line with the format-specific converter samples for IFC, Binz and Revit from the previous releases, which were replaced by this commandline sample.

Note that in combination with the MinZ and MaxZ properties from the GeoJSON output, you can obtain the 3D bounds of the objects.

• Added a version configuration option to generate either 1.0 or 1.1 OGC 3D Tiles for datasets with a 'Mesh' data category, such as BIM, OBJ or GLB datasets.
• OGC 3D Tiles 1.0 and 1.1 mesh datasets can now be reprocessed to change the version or compression type.

You can now configure the WFS feature types used by your WFS services, using both the LuciadFusion Studio web application and its REST API. In the web application, you can find a new tab Publish Info for each WFS service, enabling you to configure the WFS feature types for a selected service. Additionally, we have introduced new REST API endpoints that enable you to configure the feature types programmatically:

• GET /api/services/{serviceId}/products/{productId}: Retrieve the current feature type information, included in the publishInfo property, for a specific WFS Service and Product.
• PUT /api/services/{serviceId}/products/{productId}: Update the feature types by modifying the feature type list in the publishInfo property for a specified WFS Service and Product.

The TLcdOGC3DTilesModelEncoder now allows specifying the OGC 3D Tiles version when encoding 3D Tiles. The version can be set using the setTileSetVersion method, which accepts an ELcdOGC3DTilesVersion argument.

• The default version is VERSION_1_0, which is the earlier version of the OGC 3D Tiles specification.
• Not all features of VERSION_1_1 are used. An overview of differences between data exported with the two versions can be found in the ELcdOGC3DTilesVersion javadoc.

Added support for Azure Maps, a geospatial mapping service provided by Microsoft. It offers data such as worldwide road maps and high-resolution imagery. You can decode an Azure Maps model for a desired map and visualize the resulting data in GXY and Lightspeed views.

For more details, see the Azure Maps entry in the Data Formats documentation section.

Please note that Azure Maps is introduced by Microsoft as the successor of Bing Maps. Only enterprise account customers can continue using Bing Maps for Enterprise services until June 30th, 2028. Free (Basic) account customers can no longer use Bing Maps and need to switch to Azure Maps.

You can now display DGN data on a Lightspeed view with proper styling.

See TLspDGNStyler and TLspDGNLayerFactory for details.

The existing limitations of decoded objects and styling in GXY still apply.

You can now display DWG and DXF data on a Lightspeed view with proper styling.

See TLspDWGStyler and TLspDWGLayerFactory for details.

The existing limitations of decoded objects and styling in GXY still apply.

We now pick up the WKT geo-reference, part of the "user coordinate system", inside the LGSx file.

If there is no geo-reference in the file, but you know it and want to apply it, use a .prj file next to your .lgsx file.

Do note that the user coordinate system can only be applied to the panoramic photos, not the HSPC point cloud. This is because we expose the HSPC that is inside the LGSx file as-is directly.

If you don't want to apply the user coordinate system to the panoramas, you can set system property -Dcom.luciad.format.lgsx.useCoordSys=false.

If you have a dataset with user coordinate system and need to apply it to both the panoramas and the point cloud, we advise to apply it on the client.

• A isAutoGenerated() method to determine if the primary key is autogenerated or not. When it is not known if the key is autogenerated or not, false is returned.
• A TLcdPrimaryKeyAnnotation(TLcdDataProperty, boolean) constructor to specify whether the key is autogenerated or not.

• The first data source can be used 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 georeferenced GXY or Lightspeed view.
• The second data source can be used to decode the NITF data into a non-georeferenced model. This model is an ILcdModelTreeNode with a sub-model for each NITF data segment. The resulting model can be used to visualize the data in a GXY view with a CRS:1 reference or to publish the data in a LuciadFusion WMS service that has CRS:1 reference support. This is described in the LuciadFusion article "How to set up a non-georeferenced WMS".

• Symbol.FrameWidth: specifies the frame width of icon symbols, expressed in pixels.
• Symbol.FrameColor: specifies the frame color of icon symbols.
• Symbol.AlternateFillColor: specifies color used to fill the part of the symbol frame, that is not covered by the fill percentage.
• Symbol.ForcedColor: overrides the standard affiliation color of a symbol

The TLcd3DTilesProcessorBuilder now allows specifying the OGC 3D Tiles version when creating the 3D Tiles processor. The version can be set using the tileSetVersion method, which accepts an ELcdOGC3DTilesVersion argument.

• The default version is VERSION_1_0, which is the earlier version of the OGC 3D Tiles specification.
• Not all features of VERSION_1_1 are used. An overview of differences between data exported with the two versions can be found in the ELcdOGC3DTilesVersion javadoc.

The Draco library has been upgraded to version 1.5.7.lcd-6.

With this upgrade, a Linux ARM 64-bit version of this library is added, while the win32 version is removed. We also improved memory usage when decoding a Draco compressed dataset.

This library is used by the TLcdOGC3DTilesModelEncoder and allows you to use Draco compression on 3D mesh and point cloud data.

• Windows, starting from Windows 10 and Windows Server 2016
• macOS, starting from macOS 13

• ALcdWMSLayer#getBoundingBox(String) allows to retrieve a bounding box for a given coordinate reference system.
• TLcdWMSLayer#addBoundingBox(String, ILcdBounds) allows to register a bounding box for a given coordinate reference system.

The class TLcdBingMapsTransportFactory which was deprecated since 2013 has been removed. The features of the deprecated class like caching etc. are now available through the TLcdTransportFactory class. If you are using the TLcdBingMapsTransportFactory class, you can replace it with the following code:

TLcdTransportFactory transportFactory = new TLcdTransportFactory();
transportFactory.setCaching(true);
transportFactory.setMaxCacheEntries(1000);
transportFactory.setRetryCount(3);
    

The TLcdMrSIDModelDecoder#canDecodeSource method no longer accepts .sdw files. The main entry point for a MrSID data set is the .sid file, as indicated by the class documentation of TLcdMrSIDModelDecoder. The .sdw file is only a supporting file.

This fix avoids that a MrSID file that gets added to LuciadFusion results in two similar data items. Users that used the .sdw file as the entry point of a data set can simply switch to the .sid file.

• TLcdNITFUncompressedImageDecoder has been removed.
• TLcdNITFModelDecoder#decodeImageBounds has been removed.
• TLcdNITFModelDecoder#decodeModelReference has been removed.
• TLcdNITFTextSegment now has a copy constructor.
• TLcdNITFModelDescriptor#addTextSegment has been added.

The names of the DWG native jar files have been revised to indicate the library version update from 24.8 to 26.2. Version 26.2 aligns with the latest release of the OpenDesignAlliance's Drawings SDK, version 2026.2.

The available DWG native jar files, at the time of writing, are:

• libdwg-26.2.lcd-1-native.linux64.jar
• libdwg-26.2.lcd-1-native.linux64_arm.jar
• libdwg-26.2.lcd-1-native.macos_64.jar
• libdwg-26.2.lcd-1-native.macos_64_arm.jar
• libdwg-26.2.lcd-1-native.win64.jar

The names of the DGN native jar files have been revised to indicate the library version update from 24.8 to 26.2. Version 26.2 aligns with the latest release of the OpenDesignAlliance's Drawings SDK, version 2026.2.

The available DGN native jar files, at the time of writing, are:

• libdgn-26.2.lcd-1-native.linux64.jar
• libdgn-26.2.lcd-1-native.linux64_arm.jar
• libdgn-26.2.lcd-1-native.macos_64.jar
• libdgn-26.2.lcd-1-native.macos_64_arm.jar
• libdgn-26.2.lcd-1-native.win64.jar

The TLcdIFCModelDecoder returns a feature data model with an ILcdDataObject. The TLcdDataModel of that ILcdDataObject has been changed to align it with the feature data models of other BIM formats. The data model now has:

• A new property with the name Metadata. This property is a Map and contains the non-categorized metadata of the object as found in the IFC dataset. In previous versions, the ILcdDataObject itself contained this metadata.
• A new property with the name MetadataGroups. This property is a Map and contains the metadata within the different IfcPropertySets linked to the object in the IFC dataset. In previous versions, an array of IfcPropertySet elements contained this information.

The following image shows an illustration of the new TLcdDataModel (on the right) compared to the old TLcdDataModel (on the left).

Comparison of the old and new IFC feature model

The geometry model returned by the TLcdBinzModelDecoder no longer contains the metadata of the objects. Only the FeatureID is retained in the geometry model. This change has an impact on the OGC 3D Tiles generation process: it now stores only the FeatureID inside the batch table. Depending on the amount of metadata inside the Binz dataset, this can lead to a significant reduction in the size of the OGC 3D Tiles output.

The metadata of the objects is still available in the feature data model. The FeatureID in the geometry model can be used to match the objects in the geometry model with the objects in the features model. If you have code that reads out the metadata directly from the OGC 3D Tiles data, you must change this code to read this metadata from the feature data model. The Visualize BIM data article explains this in more detail.

The TLcdBinzModelDecoder returns a feature data model with elements implementing the ILcdDataObject interface. The TLcdDataModel of these elements has been changed to align it with the feature data models of other BIM formats. These changes were made:

• Added a property with the name Metadata. This new property is a Map and contains the non-categorized metadata of the object as found in the Binz dataset. In previous versions, the ILcdDataObject itself contained this metadata.
• Removed the RenderId property. This property was used to store the original FeatureID of the feature in the Binz dataset. Instead, a FeatureIDOffset property is stored in the root feature of the model. You can use this property to calculate the original FeatureID by subtracting this offset from the FeatureID property of the object.
• The features in the model no longer implement the ILcdExtrudedShape interface. Instead, this information can be derived from the Bounds, MinZ and MaxZ properties.

You must change code that reads out this Binz metadata to use this new structure. This snippet shows a code example of how to read the moniker Binz property in a previous version of the model:

// will no longer work in 2025.0
TLcdBinzModelDecoder decoder = new TLcdBinzModelDecoder();
ILcdModel featuresModel = decoder.decodeSource(new TLcdBIMDataSource("path/to/dataset.binz", FEATURES));
ILcdDataObject feature = (ILcdDataObject) featuresModel.elements().next();
String moniker = (String) feature.getValue("moniker");

To work with the new model, change the code to retrieve the Metadata property first. This property is a Map containing the Binz metadata, like the moniker. This snippet shows how to read this moniker property in the new version of the model:

TLcdBinzModelDecoder decoder = new TLcdBinzModelDecoder();
ILcdModel featuresModel = decoder.decodeSource(new TLcdBIMDataSource("path/to/dataset.binz", FEATURES));
ILcdDataObject feature = (ILcdDataObject) featuresModel.elements().next();
Map<String, Object> metadata = (Map<String, Object>) feature.getValue("Metadata");
String moniker = (String) metadata.get("moniker");

The RenderId property is no longer available on the features in the model. Instead, you can now calculate it by subtracting the FeatureIDOffset from the FeatureID. This snippet shows a code example of how to accomplish that:

TLcdBinzModelDecoder decoder = new TLcdBinzModelDecoder();
ILcdModel featuresModel = decoder.decodeSource(new TLcdBIMDataSource("path/to/dataset.binz", FEATURES));

// Get some feature
ILcdDataObject feature = (ILcdDataObject) featuresModel.elements().next();

// Get the root feature
Integer rootFeatureId = ((List<Integer>) feature.getValue("AncestorPath")).get(0);
ILcdDataObject rootFeature = (ILcdDataObject) featuresModel.query(...);

// Calculate the RenderID
Integer featureId = (Integer) feature.getValue("FeatureID");
Integer featureIdOffset = (Integer) rootFeature.getValue("FeatureIDOffset");
Integer renderId = featureID - featureIdOffset;

Casting a Binz feature to an ILcdExtrudedShape now results in a ClassCastException because the feature no longer implements this interface. This snippet shows a code example of how to convert a Binz feature into an ILcdExtrudedShape in the new version of the model:

TLcdBinzModelDecoder decoder = new TLcdBinzModelDecoder();
ILcdModel featuresModel = decoder.decodeSource(new TLcdBIMDataSource("path/to/dataset.binz", FEATURES));
ILcdDataObject feature = (ILcdDataObject) featuresModel.elements().next();
ILcdExtrudedShape shape = new TLcdExtrudedShape(ALcdShape.fromDomainObject(feature),
                                                (Double) feature.getValue("MinZ"),
                                                (Double) feature.getValue("MaxZ"));