About this release

With this 2022.0 release, LuciadFusion is ready for GeoBIM. Data in the IFC format is now directly supported. Our customers in the defense domain can now benefit from DGIWG-compliant OGC WMS and WMTS services. Furthermore, we added an important set of improvements and enhancements that were high on our customers' wish lists.

luciad portfolio
Figure 1. The Luciad Product Portfolio.

Benefits of the new features

Support for Building Information Models (BIM) in the IFC format

The Industry Foundation Classes (IFC) format is an open file format used by Building Information Modeling (BIM) programs. It contains a model of a building or facility, including spatial elements, materials, and shapes. In recent years, GeoBIM has become necessary for bringing situational awareness into infrastructure projects, and vice versa.

This 2022.0 release of LuciadFusion brings support for IFC. The IFC models can be discovered via the crawling capability and set up as an OGC 3D Tiles service. Indeed, for efficient visualization, IFC data is best converted into OGC 3D Tiles. This conversion is integrated within LuciadFusion Studio and the LuciadFusion Platform, transparent to the Studio user. Multiple IFC models can be combined into one 3D Tiles dataset, if required.

IFC models contain geometries as well as metadata. LuciadFusion allows you to correlate between the OGC 3D Tiles data and the properties inside the IFC. These properties can then be used to style, filter, or select elements from the IFC model.

ifcsample
Figure 2. IFC data delivered through LuciadFusion, and visualized in LuciadRIA, showing the properties of a selected element.

For easy access to the metadata, LuciadFusion offers a tool to convert the IFC dataset into the GeoJSON format. This conversion maintains the properties stored inside the IFC dataset, together with a bounding box of each item. The unique identifier stored inside the 3D Tiles data is also present in the GeoJSON data. You can perform this conversion to GeoJSON programmatically, or you can run a convenient IFC data conversion script from the command line.

All capabilities related to the discovery and serving of IFC data are also available via the REST API. The tiling engine API is available as a stand-alone capability.

Sample code to get you started

The decoder sample is the main access point for testing the LuciadFusion IFC support. Furthermore, several articles have been added to complete the product documentation with information about the format IFC and how to handle it. This information is easily accessible through Data formats: IFC and Serving IFC data from LuciadFusion Studio.

DGIWG-compliant OGC WMS and WMTS services

The Defence Geospatial Information Working Group (DGIWG) is the multi-national body established by a memorandum of understanding between the defense organizations of respective nations. Its main objective is to provide strategic guidance and recommendations on the standardization of geospatial data, products, and services and in the end achieve target levels of interoperability across coalition networks.

DGIWG’s geospatial standards make use of existing international standards where practical. This includes the geospatial web service standards developed by the Open Geospatial Consortium (OGC). It profiles and extends these standards as needed to address defense requirements.

In this release of LuciadFusion, we have focused on the OGC WMS and WMTS services, ensuring that they are DGIWG-compliant. While LuciadFusion already offered most of the required capabilities from the specification in previous versions, it did not guarantee yet the proper service metadata needed for DGIWG compliance. The LuciadFusion Platform and the LuciadFusion Studio app have been extended to facilitate the necessary configuration.

create wms service metadata
Figure 3. You can now configure OGC WMS and WMTS services to be DGIWG-compliant in LuciadFusion.

Sample code to get you started

The article How to make your LuciadFusion WMS or WMTS service DGIWG-compliant describes how to ensure all is set up properly.

Support for GetLegend requests

LuciadFusion now supports the “GetLegend” request for OGC WMS and OGC WMTS services. By default, the LuciadFusion Platform responds with an icon graphic if it receives a GetLegendGraphic request from a WMS or WMTS service. The icon depends on the type of model linked to the server layer: elevation, raster, or vector. In addition, the LuciadFusion Platform allows you to customize the legend encoding for the WMS and WMTS services. More information, including sample code, can be found in the newly added article How to customize the legend encoding.

Encode the GetFeatureInfo response in XML

The OGC WMS GetFeatureInfo response can now be provided in XML, in addition to the already available encoding in JSON.

Support for rotations in WMS map requests

By definition, a WMS map request includes coordinates that determine the area to be visualized. When the resulting map needs to be used on a rotated view in an application, labels and icons might no longer appear in the desired orientation; for example, labels are no longer rendered upright. To improve this, the WMS server of LuciadFusion now supports server-side map rotations: by including an ‘angle’ parameter in the WMS map request, LuciadFusion will now return the desired map rotation around the center in degrees. Because the rotation is done on the WMS server itself, labels and oriented icons are positioned correctly on the returned rotated maps. See How to keep labels upright when rotating maps for more information.

Upgrade of the OGC server samples to Java Servlet 3

the OGC Server samples in LuciadFusion have been upgraded to make use of Java Servlet 3 capabilities. The most important change is the replacement of the legacy XML deployment descriptors with annotations on the servlets. A direct benefit is the easier integration of the OGC services with Spring Boot, one of the most widely used frameworks to run applications and services.

Extended OGC SE styling capabilities

OGC Symbology Encoding (SE), previously called Styled Layer Descriptor (SLD), is a standard for cross-platform and cross-vendor style definition. It mainly focuses on vector data, but also includes some parameters for defining the appearance of raster data.

OGC SE is widely used. Nevertheless, its expressive power is limited with respect to label styling options. This is one of the primary reasons for the industry to introduce the concept of vendor options. Vendor options are key/value pairs that can be set on a symbolizer to customize settings that are not available in OGC SE.

This mechanism has already been used within the Luciad Portfolio products for labeling. A typical use case is street labeling. Now we have used the concept of vendor options to support the label box styling settings.

se labelbox
Figure 4. A set of vendor options to support the label box styling settings is now available in LuciadFusion.
Styling the points of a line-based shape

You can now style the points of a line-based shape. When you use a PointSymbolizer with the Geometry function “vertices”, the defined point style is applied to all points of the encountered shape. An example use case is the styling of waypoints along an ATS route.

Extended PointSymbolizer capabilities

You can now use the geometry function “interiorPoint” to style a shape using a PointSymbolizer. This function takes a point in the middle of the shape border itself if it is open, or inside the shape if it is closed.

Changing the anchor point of icons

You can now adjust the anchor point of icons in OGC SE, by using the AnchorPoint property on a PointSymbolizer graphic. An example use case is the alignment of the tip of an arrow icon with the end of a line segment.

se pointsymbolizer
Figure 5. Extended PointSymbolizer capabilities.

Sample code to get you started

The existing OGC SE samples have been extended. For the label box styling, see the article How to draw a box around labels.

Area calculation for complex polygons with holes

You can calculate the area of a surface with one of these three methods:

  • TLcdEllipsoidUtil.geodesicArea(ILcdShape, ILcdEllipsoid) for shapes with longitude/latitude coordinates

  • TLcdSphereUtil.geodesicArea(ILcdShape, double) for shapes with longitude/latitude coordinates

  • TLcdCartesian.area(ILcdShape) for shapes with Cartesian (X/Y) coordinates

All these functions now support complex polygons, including islands and holes.

area calculation example
Figure 6. An example of the area of Italy, the country borders of which make up a complex polygon.

Sample code to get you started

A new how-to article has been added. See How to calculate the area of a complex polygon.

Improvements for customers in the aviation domain

Apply constructive geometry to AIS shapes

Since early versions of LuciadFusion, topological checks and constructive geometry operations have been possible. This capability has now been extended for aeronautical objects, that are decoded as so-called “AIS shapes” by the LuciadFusion API. It is particularly relevant to all polyline- and polygon-like objects.

airspaceCreation 3
Figure 7. Through a custom Lucy add-on, AIS airspace shapes and constructive geometry operations are combined to create the Churchill Low Military Operations Area (MOA) in Nevada. The MOA consists of a polygonal airspace volume from which a circular airspace volume is subtracted.
Sample code to get you started

This capability has been integrated into the Constructive Geometry sample.

DAFIFT support for Minimum Sector Altitude data

The decoder for the DAFIFT aviation data format now supports the decoding and visualization of Minimum Sector Altitude data. This data defines the lowest altitude that provides a minimum clearance of 1000 feet above all objects located within a circle sector around a navigational aid, for example.

Other improvements

Draco compression for point clouds

LuciadFusion now supports Draco compression for point cloud data encoded as 3D Tiles. This extends the existing capability supporting Draco compression for 3D Tiles meshes data.

Improved Java 17 support

The Java 17 support has been further improved:

  • This release removes a series of package splits over distinct jar files. Please consult the related upgrade consideration on the Release notes page for the details.

  • There were some changes in third-party libraries to improve the compatibility with Java 17. For example, the samples now depend on the HikariCP third-party library. It is used to illustrate how the database model decoders can use a database connection pooling framework. The version of Ehcache was also updated from 3.2.0 to 3.10.0. Such changes are documented as an upgrade consideration in the Release notes as well.