Developer’s Corner: Simplify Complex Features with GeoServer and HALE

GeoServer

Dear Readers,

as a follow up to our previous post INSPIRE Support in GeoServer made easy with HALE, in this installment we would like to tell you about the progress we have done in making HALE and GeoServer work together to facilitate the setup of INSPIRE compliant services. We anticipated that we were developing a plugin for HALE to automatically convert a HALE Alignment to an app-schema configuration. Here, we will explore in greater detail the plugin’s current (and future) capabilities.

 

BASIC WORKFLOW

The plugin has been designed to have as little impact on the regular HALE user as possible, so the basic workflow to produce a HALE alignment still applies:

  • import source and target schemas
1

Source schema imported from a PostGIS database

2

Target schema imported from a remote XSD file

3

Source and target schemas have been imported and filtered

 

  • define the transformation functions which compose the alignment

 

4

Alignment mapping land cover data to the Land Cover Vector INSPIRE schema

 

GEOSERVER COMPATIBILITY MODE

At this stage, not every single HALE function can be automatically translated to app-schema mapping directives.

Currently supported functions include:

i. Type relations

  • Retype
  • Join

ii. Property relations

  • Assign
  • Date extraction
  • Formatted string
  • Mathematical expression
  • Rename
  • Classification

 

Support will likely be extended to more functions in the future, but, in the meantime, to help the user discern which functions are compatible with app-schema and which aren’t, we introduced a GeoServer compatibility mode. Once the mode is activated, the mapping function selection menu in the schema explorer view will only list the functions which are compatible with the GeoServer app-schema extension, and a red cross will appear at the bottom right corner of the window if the alignment cannot be automatically translated to an app-schema configuration

 

5

GeoServer compatibility mode is on, no incompatibility detected

 

6

GeoServer compatibility mode is on, incompatibility was detected

 

EXPORT MODES

Once the alignment has been defined, it must be exported to produce a valid app-schema configuration for GeoServer.

Two complementary export approaches are available:

  • App-Schema Configuration: the configuration is saved to one or more files, which must be manually copied / extracted to the right place in the GeoServer data directory. This approach may be preferred during testing, or when a live GeoServer instance is not available or not accessible.
  • App-Schema Configuration [Direct Upload]: the configuration is generated and immediately uploaded to GeoServer via its REST API. This approach is more convenient and should generally be preferred.

 

7

Export format dialog

Regardless of the chosen export format, the generation of app-schema mappings from the defined alignment is fully automatic and all the necessary information is gathered from the user through a few configuration screens in the export wizard.

 

DATASTORE CONFIGURATION

GeoServer’s app-schema extension works on top of regular datastores producing simple features, which are then composed to build complex features. Hence, a valid app-schema mapping configuration must define one or more source datastores.

The HALE app-schema export wizard provides an ad-hoc configuration dialog where the user can enter all settings required to establish a connection to the source datastore.

8

DataStore configuration dialog

So far, only a single PostGIS datastore can be configured, but there are plans to extend this functionality to make the setup of multiple datastores possible, as well as to support more store types (e.g. Oracle, Shapefiles, etc…).

 

FEATURE CHAINING

One of the most powerful features of app-schema is its ability to compose complex features by chaining simpler components (Feature Chaining): this allows to reduce duplication, as data can be modelled according to best practices (i.e. as a set of normalized tables), without affecting performance (at least when the backing datastore is a relational database).

A common use case is mapping a one-to-many relationship between a container type and a nested type: examples include LandCoverDataset (container) and LandCoverUnit (nested) in the INSPIRE Land Cover Vector application schema, or GeologicUnit (container) and CompositionPart (nested) in GeoSciML.

The HALE app-schema plugin fully supports these complex mappings by leveraging HALE’s Join transformation function.

9

Three source types are joined to produce a single target type, LandCoverDataset

10

HALE’s Join configuration wizard allows to specify join conditions

 

If one or more Join functions have been defined in the alignment, the app-schema export wizard will create a variable number of configuration dialogs, asking the user to specify how the types participating in the join should be chained together to produce the target type.

11

Feature Chaining configuration: the LandCoverUnit type will be nested under the member property of the LandCoverDataset type

 

The entire configuration requires just a few clicks: a big improvement over the error-prone manual typing of XML data required so far!

 

FREE TRAINING AVAILABLE NOW!

This post has given just a quick overview of the main features of the plugin, but we have prepared extensive documentation that goes more in-depth into the subject and a full training package complete with all the tools you need to try the software yourself and reproduce the examples described in the docs.

 

FUTURE WORK

As we have seen, the HALE app-schema plugin, despite being still a work in progress, already provides useful features that ease the pain of setting up GeoServer to serve complex feature types.

However, stay tuned as we plan to extend the software in several respects:

  • out of the box support for more HALE transformation functions
  • support for conditional mappings via property filters
  • support for a greater number of datastore types
  • definition of configuration profiles to persist settings between exports
  • automatic handling of nillable mandatory elements
  • better handling of GML IDs

 

All the work done on HALE so far has been released as Open Source and lives in a feature branch of the official hale repository. We are actively working together with the HALE community on improving the software, with the aim of merging it into the HALE master branch in the near future. GeoServer-side, several improvements and fixes have been developed in the context of this project and they are already available in GeoServer as of release 2.8.0: any further work will become part of the code base as soon as it is done and will be available in the upcoming GeoServer release.

 

If you want to know more about how we can help your organization, don’t hesitate and get in touch with us!

The GeoSolutions Team,

Geosolutions

 

Leave a Reply