This guide explains how you can migrate from LuciadFusion V2016.1 to the LuciadFusion architecture introduced with V2017. For migration from older versions of LuciadFusion, we refer to the upgrade considerations in the release notes of LuciadFusion V2016.1 and before.

Unless otherwise stated, the instructions in this guide are also valid for migrations to a LuciadFusion version more recent than V2017.

Do I need to migrate to LuciadFusion V2017 or later?

In line with our policy, we will maintain LuciadFusion V2016 for as long as we have customers that actively use these versions and are under maintenance contract. Major versions are maintained by releasing subsequent minor versions, V2016.1, V2016.2, for example.

This means that LuciadFusion V2016 remains available and you can decide when to migrate.

Compatibility of V2017 (or later) client applications with LuciadFusion V2016.1

The compatibility of LuciadFusion V2016.1 with LuciadRIA V2017 client applications is the same as its compatibility with the V2016.1 versions of these products.

For LuciadLightspeed, there are two changes:

  • The LuciadLightspeed capability to connect to LuciadFusion VECTOR coverages (served through LTS or read locally) has been deprecated. This means that we advise you to start serving your vector data through other protocols than the LTS vector tiles. A good alternative is OGC WFS, for example. In V2017, you can serve any vector data through WFS without coding, so you may want to consider upgrading when you decide to move away from LTS vector tiles for serving your vector data.

  • LuciadLightspeed V2017 has simplified access to LuciadFusion coverages through the TLcdCoverageModelDecoder. It can be used to connect to any supported coverage type, both locally and remotely.

Setting up my data with LuciadFusion Platform

LuciadFusion Platform (V2017.0 or later) offers the choice between:

  • Direct, on-the-fly publication of data

  • Pre-tiling or fusing data before publication

In many cases, on-the-fly publication is the recommended approach. In this article, we explain how to serve coverages that you have processed using LuciadFusion V2016.1 and how to serve your data on-the-fly, using LuciadFusion Platform.

Serving data processed with LuciadFusion V2016.1

Using LuciadFusion V2016.1, you have created Tile Stores containing various types of coverages:

  • IMAGE coverages

  • RASTER coverages

  • ELEVATION coverages

  • MULTI-VALUED coverages

  • VECTOR coverages

  • NON-TILED coverages

The following sections explain for each coverage type how you can set up LuciadFusion V2017 to serve it.

Serving IMAGE, RASTER, and ELEVATION coverages

Using LuciadFusion V2017, you can crawl for your IMAGE, RASTER, and ELEVATION coverages and publish them through OGC and LTS services from the LuciadFusion Studio.

To crawl for your coverages, point your LuciadFusion Studio to the folder containing your Tile Store. The tilestore.xml file is ignored. All the XML files inside the Coverages directory are recognized by the crawler, and appear in the Data tab of LuciadFusion Studio.

From this point on, you can publish them. LuciadFusion Studio will guide you to the appropriate protocols for serving your coverages.

For more information, see the LuciadFusion Studio user guide that comes with the application.

MULTI-VALUED coverages

MULTI-VALUED coverages were originally introduced for the fusing of GRIB data specifically. In V2017, the GRIB support has improved. As a result, GRIB data can now be fused into RASTER coverages, similar to NetCDF data. Support for MULTI-VALUED coverages has been removed for reasons of technical consistency. You can now serve GRIB data both on-the-fly, or after processing it into RASTER coverages. See On-the-fly serving of data for more information about on-the-fly serving. For more information about serving RASTER coverages, see Serving coverages created with LuciadFusion Platform and I use the Data Connectivity Manager (DCM) to tile my data.

VECTOR coverages

Using LuciadFusion V2016.1, you were able to fuse vector data in the formats SHP, VPF, MAP/MIF, PostgreSQL PostGIS, and GML 2/3 (Simple Features) to VECTOR coverages. You always had the option of fusing those formats, and all other formats, to IMAGE coverages as well. When you are fusing VECTOR coverages, proper configuration of such coverages is important to get the desired multi-resolution result.

Because vector data sets tend to get bigger and bigger, and data changes increasingly frequently, we put forward serving vector data on-the-fly as the default in LuciadFusion Platform. You can now serve vector data without coding, and without configuration. Therefore, we have removed the capability to serve VECTOR coverages via LTS from the LuciadFusion Platform and, for consistency, the support for the creation of VECTOR coverages has been removed from the DCM and from the LuciadFusion Engine. For information about how to continue serving your vector data via VECTOR coverages using LuciadFusion V2016.1, see Ensuring LuciadFusion Platform compatibility with V2016.1 clients.

You can use LuciadFusion Studio to discover, configure and serve your vector data with LuciadFusion Platform. For more information, see the LuciadFusion Studio user guide.

NON-TILED coverages

A NON-TILED coverage is a specific type of coverage that stores asset sources in the Tile Store, instead of a tile pyramid. This coverage type was available for a specific set of formats like S-57/S-63 and ECW. LuciadFusion Platform allows you to serve data from the source data format, so the NON-TILED coverage type became redundant. You can now crawl all the data you used to serve via NON-TILED coverages and directly publish the data through OGC and LTS services using LuciadFusion Studio. For more information, see the LuciadFusion Studio user guide.

On-the-fly serving of data

You can serve most data natively, without processing, using LuciadFusion Platform. Use LuciadFusion Studio to discover, configure and serve your data. For more information, see the LuciadFusion Studio user guide.

Note that for some data types, it is still relevant to process the data into coverages. LuciadFusion Platform contains a tiling engine and offers the Data Connectivity Manager (DCM) for the creation and configuration of coverages. See I use the Data Connectivity Manager (DCM) to tile my data for more information on using the DCM.

Serving coverages created with LuciadFusion Platform

Raster data can still be fused in coverages. For more information about using the DCM in LuciadFusion Platform, see I use the Data Connectivity Manager (DCM) to tile my data. For guidance on when to fuse data in coverages, and when to serve it on-the-fly, see Pre-process data or serve it on the fly.

For serving ELEVATION, RASTER, and IMAGE coverages created using LuciadFusion Platform, you can use the same approach as described in Serving IMAGE, RASTER, and ELEVATION coverages.

Ensuring LuciadFusion Platform compatibility with V2016.1 clients

LuciadFusion Platform preserves all protocols supported in V2016.1. For the LTS protocol, the capability to serve vector tiles has been removed. See VECTOR coverages for more information.

Let’s start by having a look at the end points used by LuciadFusion V2016.1, and therefore expected by the V2016.1-based client applications:

  • LuciadFusion/lts: used for all fused coverages.

  • LuciadFusion/wms: used for all coverage types. All coverages were automatically published via WMS and added to this end point.

  • LuciadFusion/wfs: used for VECTOR coverages. They were all automatically added.

  • LuciadFusion/wmts: used for raster coverages of the IMAGE type with square pixels.

  • LuciadFusion/wcs. used for all coverages of types IMAGE, ELEVATION, or RASTER.

LuciadFusion Platform allows the data administrator to choose which end point and service to use for each data set. A service can have one or more end points.

LuciadFusion Platform end points are created as follows:

  • lts/{instanceName}: for fused coverages, as described in Serving data processed with LuciadFusion V2016.1 and Serving coverages created with LuciadFusion Platform.

  • ogc/wms/{instanceName}: for all supported data formats, including LuciadFusion coverages.

  • ogc/wfs/{instanceName}: for all supported vector data, served on-the-fly.

  • ogc/wmts/{instanceName}:for all supported data formats, including LuciadFusion coverages.

  • ogc/wcs/{instanceName}: for all supported raster data formats, including LuciadFusion RASTER coverages.

  • tileengine/lts: used by the Data Connectivity Manager (DCM) to control the Tiling Engine. You can configure the Fusion Platform server to use your existing tile store (2016 and before) on this end point. Find the value of the parameter fusion.tilestore.home in the web deployment descriptor file web.xml.

V2016.1 client applications experience the least impact if the LuciadFusion Platform is configured to create one end point per service, for all data. In many organizations, web applications are consolidated behind a web server like Apache HTTP Server, and client applications do not communicate directly with the server application. In such a setup, you can configure proxy end points for the V2016 end points onto the Platform end points. Alternatively, if you do not have such a setup, you can make use of existing tools/libraries to set up a proxy. For an example of such a proxy servlet, see https://github.com/mitre/HTTP-Proxy-Servlet.

I use the Data Connectivity Manager (DCM) to tile my data

The Data Connectivity Manager is available in both LuciadFusion V2016.1 and LuciadFusion V2017.0 or later. LuciadFusion Platform offers on-the-fly publication of data. This is recommended for most data sets. In some cases, fusing data into coverages is recommended. See Serving coverages created with LuciadFusion Platform for more information.

You can find the full list of upgrade considerations for the Data Connectivity Manager in the release notes. The most important changes are:

  • GRIB data is now supported through the NetCDF format addon, and fusing GRIB data results in RASTER coverages instead of MULTI-VALUED coverages. This change offers many benefits, including the ability to directly publish GRIB data into multi-dimensional WMS or WMTS services. The TLcyGRIBDecoderAddOn and TLcyLspGRIBFormatAddOn addons have been removed from the addons.xml and addons_gxy.xml files of the DCM. You can reinstate those addons by following the instructions in the release notes.

  • For LuciadFusion V2017 or later, we put forward the direct serving of vector data from the native data format as the default. Support for the creation of VECTOR coverages has been removed from the DCM. For questions on how to continue serving your vector data through VECTOR coverages using the LuciadFusion V2016.1 DCM, see Do I need to migrate to LuciadFusion V2017 or later?.

  • To emphasize the role of the DCM as a configurator for the fusion process, it is now offered as an end user application instead of as an API. See I use the Data Connectivity Manager (DCM) to tile my data for more information about migrating your custom code based on V2016.1 of the DCM.

Migrating your custom code

I have customized the DCM

LuciadFusion V2017 or later offers the DCM as an end-user application. As explained in Do I need to migrate to LuciadFusion V2017 or later?, you decide when to migrate. In the mean time, you can keep using LuciadFusion V2016.1.

Because the DCM is Lucy-based, your custom code consists of addons. Those can be plugged in to Lucy, a flexible high-level application framework that integrates all the capabilities of LuciadLightspeed. LuciadLightspeed is Luciad’s desktop solution.

If you created addons to extend the DCM in V2016.1, and they control the fusion of data, you can still develop using the Engine API. See I have customized the LuciadFusion Engine for more information. The custom code can have its own UI or be embedded in Lucy as an addon.

I have customized the LuciadFusion Engine

The Fusion Engine API remains available. You can keep using it.

Take into account that support for fusing VECTOR coverages has been removed in v2017. The V2017 Fusion Client can still read VECTOR coverages, however.

If you still need to fuse VECTOR coverages, you can keep using LuciadFusion 2016.1. You can upgrade the application using the LuciadFusion Engine later, when you are ready to continue without VECTOR coverages.

I have written custom code with the OGC Web Server suite

You can keep doing so. You may no longer have the need though, because the LuciadFusion Platform offers more functionality out-of-the-box.

LuciadFusion Platform as-is

Take some time to explore the new functionality to see if your needs are fulfilled by it. The LuciadFusion Platform is a ready-to-use server application that allows access to your data through OGC services. The Studio Web Application is the front-end application. It allows you to configure which data is published on those OGC services.

To explore the LuciadFusion Platform and Studio, start the Fusion Server within the release using the start.jar application or the Fusion Server start script. Next, go to the main page of the Studio Web Application and start exploring.

The Studio Web Application offers built-in documentation. If its functionality covers your needs, you no longer need to maintain custom code.

Custom code based on OGC server suite

The OGC Web Server Suite library components remain available for your custom OGC services code base. We have made changes to make it easier to use:

  • You can now automatically pick up model decoders, layer factories, view encoders, and feature info encoders through the service loader mechanism. This functionality is available in both the OGC Web Server Suite library components and the LuciadFusion Platform.

  • Several changes were made to the API of the OGC services. For example, you can now tailor the offered layers/coverages/feature types based on the specific request that is being handled. You can limit the offered data based on the authenticated user, or add and remove data easily without restarting the server. See the release notes for more details.

  • The performance of the WMS service has improved significantly. For instance, the performance is now much better when client applications approach the WMS with tile requests. The ability to configure caching for the result of requests for small images is now available.

Some of these changes required a change to the API. The majority of your customizations will keep working as before, without any changes. If there is an impact on existing code to the extent that you need to change it for use with V2017, you will get compilation errors. We favored the approach of compilation errors to prevent that those code changes slip by unnoticed. If you are affected, check the 'Upgrade Considerations' in the release notes of the respective components for detailed information on what to do next.

The OGC Web Server Suite Developer’s Guide has been updated to reflect the changes related to the automatic service pickup.

Extending the LuciadFusion Platform

The LuciadFusion Platform also comes with extension options. Have a look at the LuciadFusion Platform Developer’s Guide to find out what the possibilities are.