News > hale connect
News' image preview

A few months back, we described how you can setup hale connect to fully automate metadata generation, re-use and validation. In the past months, we have worked together with a reference customer, the LGL Baden-Württemberg, to extend the metadata tools in hale connect substantially. LGL Baden-Württemberg is one of 16 state-level cadastral, mapping and spatial planning authorities in Germany and maintains the state spatial data infrastructure.

The Problem

The problem that the LGL approached us with is one that we have seen many times already: there is a specific metadata profile, but both in terms of process and tools, the maintenance and implementation of this profile requires a lot of extra effort. The LGL used a massive Excel Table with more than 400 rows to describe their profile. This Excel table conflated profile rules from different levels (ISO, INSPIRE, national, and local), which all needed to be updated and kept in sync.

Excel table of requirements
Excel table containing LGL Baden-Württemberg requirements. The excel table contains rules from ISO, INSPIRE, national and local schemas.

In implementation of the profile, there were often ambiguities or different interpretations of certain aspects of the profile. Furthermore, the documentation was a bit unwieldy and hard to read for most people outside the immediate circle of editors.

Thus, LGL reached out to us to understand how they could improve on this situation. Wetransform originally conducted a UML and Metadata workshop to explore whether developing the profile in a UML Tool such as Enterprise Architect would make sense. However, some aspects such as a nice differential documentation and the generation of an executable test suite directly from the profile proved to be quite hard.

Thus, in early 2018, LGL asked wetransform to develop a toolset that would support the creation of a fully formal profile definition of the ISO metadata schemas. This toolset would enable the definition of profiles on any XML-based schema, be it the CSW 2.0.2 Application Profile ISO 1.0.0 or a GML Application Schema.

The Solution

There were several key requirements that the profile toolset should resolve:

  1. Definition of type and property constraints (e.g. on cardinality, allowed content and allowed property types.)
  2. Definition of consistency constraints (e.g. “If A exists, B must also exist”) and other advanced validation rules.
  3. Addition of documentation via tagged values.
  4. Automated generation of printable documentation.
  5. Automated generation of differential documentation.
  6. Automated generation of Executable Testsuites (ETS) for the INSPIRE Reference Validator (ETF.)
  7. Automated generation of example XML instance documents for the profile.
  8. Be easy to use for people without in-depth knowledge in technologies such as XML, XML Schema, Schematron and ETF.

A few months back, we described how you can setup hale connect to fully automate metadata generation, re-use and validation. In the past months, we have worked together with a reference customer, the LGL Baden-Württemberg, to extend the metadata tools in hale connect substantially. LGL Baden-Württemberg is one of 16 state-level cadastral, mapping and spatial planning authorities in Germany and maintains the state spatial data infrastructure.

The Problem

The problem that the LGL approached us with is one that we have seen many times already: there is a specific metadata profile, but both in terms of process and tools, the maintenance and implementation of this profile requires a lot of extra effort. The LGL used a massive Excel Table with more than 400 rows to describe their profile. This Excel table conflated profile rules from different levels (ISO, INSPIRE, national, and local), which all needed to be updated and kept in sync.

Excel table of requirements
Excel table containing LGL Baden-Württemberg requirements. The excel table contains rules from ISO, INSPIRE, national and local schemas.

In implementation of the profile, there were often ambiguities or different interpretations of certain aspects of the profile. Furthermore, the documentation was a bit unwieldy and hard to read for most people outside the immediate circle of editors.

Thus, LGL reached out to us to understand how they could improve on this situation. Wetransform originally conducted a UML and Metadata workshop to explore whether developing the profile in a UML Tool such as Enterprise Architect would make sense. However, some aspects such as a nice differential documentation and the generation of an executable test suite directly from the profile proved to be quite hard.

Thus, in early 2018, LGL asked wetransform to develop a toolset that would support the creation of a fully formal profile definition of the ISO metadata schemas. This toolset would enable the definition of profiles on any XML-based schema, be it the CSW 2.0.2 Application Profile ISO 1.0.0 or a GML Application Schema.

The Solution

There were several key requirements that the profile toolset should resolve:

  1. Definition of type and property constraints (e.g. on cardinality, allowed content and allowed property types.)
  2. Definition of consistency constraints (e.g. “If A exists, B must also exist”) and other advanced validation rules.
  3. Addition of documentation via tagged values.
  4. Automated generation of printable documentation.
  5. Automated generation of differential documentation.
  6. Automated generation of Executable Testsuites (ETS) for the INSPIRE Reference Validator (ETF.)
  7. Automated generation of example XML instance documents for the profile.
  8. Be easy to use for people without in-depth knowledge in technologies such as XML, XML Schema, Schematron and ETF.

To fulfil these, we developed a formal model that could capture all the required information, as well as a set of editing functions that extend the existing schema modelling tools in hale connect. The formal profile contains type and property constraints, consistency constraints and tagged values:

Formal profile model
Formal profile model diagram. The diagram displays the formal profile model developed by wetransform.

To create a profile, you first have to create a schema using any of the methods supported in hale connect. For creating a metadata profile, use either the ISO 19139 preset or the CSW 2.0.2 Application Profile ISO 1.0.0 preset.

After this step, you have to create a profile of that schema. This is also done through the “Create new Schema” process, using the “Create Profile” option. When the profile has been created (which takes up to 30 seconds), you can go to the Feature Types section and start applying type and property constraints.

Type level constraints
Type level constraints. The toggle switch can be used to make a type mandatory.

To make a single type mandatory, you can just toggle it in the type header. Making it mandatory means that an object of this type has to occur at least once in any document. This is particularly useful in GML Feature Collection, where you want to state which types of objects have to be present.

Most of the constraints are set using the Edit Mode, which you can access through the Pen icon in the type header. Clicking this icon brings you to a powerful editor, where you can set a number of constraints:

  • Content Required: If not already true, you can set this to true to make sure that the given property always has to have content. The semantics of this constraint are equivalent to setting the nillable flag to false.
  • Minimum Cardinality: The minimum number of times this property needs to occur in any given type. It needs to be higher than the one defined in the schema, but lower or equal than the value given for maximum cardinality.
  • Maximum Cardinality: The maximum number of times this property needs to occur in any given type. It needs to be lower than the one defined in the schema, but higher or equal than the value given for minimum cardinality.
  • Allowed Values: In this field you can define an enumeration of the actually allowed values. If the property uses an enumeration or code list, you will be able to activate or deactivate options from that enumeration or codelist.
  • Allowed Types: If this field uses a Choice, Substitution Group or Union, you can limit the allowed types by deactivating options.

In addition, you can add any number of tagged values to each property. You can use any keys you want, but some control specific behavior:

  • label-testcase: Label for this test case in the ETF Testsuite
  • description-testcase: Description for this test case in the ETF Testsuite
  • module-id: ID of the TestModule group to which the test case generated for this property will be added
  • example: Content to be used for the generation of XML sample files. If the property is a complex element, setting this value to “true” leads to the element being generated.
Consistency constraint editor
Consistency constraint editor: Consistency constraints are added to schema elements.

The second big block of functionality is to be found in the “Consistency Conditions” section of the profile. When you go there, you will be able to define various sets of rules, such as:

  • If A exists, B must/must not exist
  • If A has value “X”, B must have value “Y”

You can combine any number of such rules through logical operators (AND, OR, XOR). To each Consistency Condition, you can add a label and a description, as well as tagged values.

Generated documentation example
Generated documentation example. Profile documentation can be printed easily.

When you want to review your profile at any time, the differential documentation is a handy feature, especially in big schemas like the ISO 19139 schema. It hides all elements (types and properties) for which no change or addition was made in the profile, resulting in a compact, well-readable format.

Either the full profile or the differential documentation can be printed to any device, specifically to PDF. This enables you to get a document that you can send around to any user.

By going to the “Files” section of the profile, you can also export sample XML instance documents for your profile.



And finally, you want to make sure that any data you receive complies with your profile. For this purpose, hale connect can also export an Executable Test Suite, again through the Files section. This ETS can be run in the ETF (INSPIRE Reference Validator).



The profile tools described here can also be used in conjunction with the metadata generation tools introduced with hale connect 1.0. Ask us to learn how to do so, especially if you are already a hale connect user.

If you want to know more about how to use these tools, check out the online help.

Getting Access to the Metadata Tools

We presented the new metadata tools at the INSPIRE conference 2018 in Antwerp just a few weeks back and can now announce general availability.

The new metadata tools are part of all hale connect licenses, independent of deployment mode and license level. While Metadata Generation has been part of hale connect since version 1.0, the profile management tools have been released with version 1.11.0, which is available since October 17th, 2018.

The tools are available starting from 2.900 € per year (Micro Org Public Cloud license). Special pricing is available for multi-year contracts, partners, and customers with support subscriptions.

Try it out for free!

(more)

News' image preview

In our daily work to publish and maintain INSPIRE-compliant view and download services for our customers, the importance of supporting the portrayal rules outlined in data specifications is ever present. We have thus been working for a long time to provide as complete as possible portrayal rules, which we provide as presets for any INSPIRE services published on our cloud platform, haleconnect.

What is an SLD, and why might I need it in INSPIRE?

The technical guidelines for each of the 34 INSPIRE themes contain a list of required or recommended layers which define the cartographic representation of data sets provided as view services. The chosen model for feature display in INSPIRE is the Styled Layer Descriptor (SLD) and Symbology Encoding (SE) standards, developed and published by the OGC.

The OGC standard SLD is an XML document that uses the OGC standards Symbology Encoding (SE) and Filter Encoding (FE) to define the cartographic rules by which to display features. The SLD standard extends the OGC Web Map Service (WMS). A basic WMS supports named layers and styles which do not enable end-users to define custom symbology. The SLD standard extends the WMS standard to allow users to provide styling rules in a Styled Layer Descriptor file. Web map services that support SLDs retrieve features from web feature services and apply the styling rules contained in the SLD.

What systems can I use to implement SLDs?

At wetransform, we use the open source framework deegree to provide OGC- and INSPIRE-compliant view and download services. deegree view services (Web Map Services) support the use of SLDs. Like most web map servers, deegree supports several deegree-specific functions which extend the SLD, SE and FE standards to enhance styling. Our development process for each SLD was to first check the examples and requirements in the INSPIRE data specification, and then to use an XML editor to iteratively implement the SLD. We directly tested is on our cloud platform haleconnect, with data sets specifically developed for this purpose. When a dataset is published on the haleconnect platform, the feature type is identified and our INSPIRE SLD library is searched for a matching style layer. INSPIRE SLDs are then applied if available.

What are the positives?

SLDs can display features with simple symbology requirements, and for many INSPIRE themes, the SLD standard is adequate. Filter encoding (FE) can be used to make selections and apply symbology to different geometries, or attributes. Many INSPIRE SLDs are based on INSPIRE codelist values. Datasets are filtered based on codelist values to obtain the desired feature sets, and symbology is applied to only those features matching the filter criteria. In other cases, SLDs are based on geometry type. At wetransform, we apply deegree-specific filter functions to filter datasets by geometry type in order to apply the correct symbology.

In our daily work to publish and maintain INSPIRE-compliant view and download services for our customers, the importance of supporting the portrayal rules outlined in data specifications is ever present. We have thus been working for a long time to provide as complete as possible portrayal rules, which we provide as presets for any INSPIRE services published on our cloud platform, haleconnect.

What is an SLD, and why might I need it in INSPIRE?

The technical guidelines for each of the 34 INSPIRE themes contain a list of required or recommended layers which define the cartographic representation of data sets provided as view services. The chosen model for feature display in INSPIRE is the Styled Layer Descriptor (SLD) and Symbology Encoding (SE) standards, developed and published by the OGC.

The OGC standard SLD is an XML document that uses the OGC standards Symbology Encoding (SE) and Filter Encoding (FE) to define the cartographic rules by which to display features. The SLD standard extends the OGC Web Map Service (WMS). A basic WMS supports named layers and styles which do not enable end-users to define custom symbology. The SLD standard extends the WMS standard to allow users to provide styling rules in a Styled Layer Descriptor file. Web map services that support SLDs retrieve features from web feature services and apply the styling rules contained in the SLD.

What systems can I use to implement SLDs?

At wetransform, we use the open source framework deegree to provide OGC- and INSPIRE-compliant view and download services. deegree view services (Web Map Services) support the use of SLDs. Like most web map servers, deegree supports several deegree-specific functions which extend the SLD, SE and FE standards to enhance styling. Our development process for each SLD was to first check the examples and requirements in the INSPIRE data specification, and then to use an XML editor to iteratively implement the SLD. We directly tested is on our cloud platform haleconnect, with data sets specifically developed for this purpose. When a dataset is published on the haleconnect platform, the feature type is identified and our INSPIRE SLD library is searched for a matching style layer. INSPIRE SLDs are then applied if available.

What are the positives?

SLDs can display features with simple symbology requirements, and for many INSPIRE themes, the SLD standard is adequate. Filter encoding (FE) can be used to make selections and apply symbology to different geometries, or attributes. Many INSPIRE SLDs are based on INSPIRE codelist values. Datasets are filtered based on codelist values to obtain the desired feature sets, and symbology is applied to only those features matching the filter criteria. In other cases, SLDs are based on geometry type. At wetransform, we apply deegree-specific filter functions to filter datasets by geometry type in order to apply the correct symbology.

Symbology encoding is used to apply scale ranges and symbology choices in SLD layers. The MaxScaleDenominator and MinScaleDenominator elements can be used to control display ranges for your datasets. We use scale ranges to control the display of Administrative Units layers, so that each administrative hierarchical level displays at only one scale range.

Map 1 - Administrative Units, Catalonia. Filter and scale range applied to Administrative Hierarchical Level 3rd order
Map 1 Administrative Units, Catalonia. Filter and scale range applied to Administrative Hierarchical Level 3rd order.
Map 2 - Administrative Units, Catalonia. Filter and scale range applied to Administrative Hierarchical Level 5th order
Map 2 Administrative Units, Catalonia. Filter and scale range applied to Administrative Hierarchical Level 5th order.

Symbology encoding also offers standard cartographic styling options. Surface features can be styled using color or graphic fill options, and opacity. Line features can be styled in various ways by applying color and opacity, line casing, dashed lines and line join options which control how line features are symbolized where they join. Point features can be symbolized using graphic symbols, such as icons, or the WellKnownName element that includes the values square, circle, triangle, star, cross, and x.

The Symbology Encoding standard (SE) also supports the styling of text labels. Font family, style and size selection are all supported. Label placement rules enable the user to control how labels are displayed in relation to the geometry they describe, including offsets, rotation and splining.

What are the challenges?

In some cases, the SLD standard cannot handle the complexity of INSPIRE data models. Feature types with properties which contain links to geometries, and indirect geometries, commonly found in the Transport Network theme, cannot be symbolized.

There are also challenges associated with the display of INSPIRE compliant, complex GML which contains multiple features with the same geometry type, which are overlapping. The Administrative Units layer displays with all administrative hierarchical levels at once, and from the perspective of the viewer, the information displayed is indiscernible. The Administrative Units theme also contains feature types with linked features, which makes partitioning by feature type problematic. As mentioned, wetransform applies scale ranges to control display in this case (See Map 1., Map 2.).

In many themes, a further challenge is the requirement to provide one SLD layer per codelist value - That’s a lot of SLD layers! Some codelists, such as those found in the Habitats and Biotopes theme, have hundreds of values. To complicate matters, codelists which exist in externally referenced documents, such as Natura200, make symbolization based on their values difficult.

In our work with the Utility and Governmental Services theme, we discovered a need for a standardized icon library for the symbolization of point geometries found in the Administrative and Social Governmental Services codelist. Objects defined in this codelist include hospitals, schools, police and fire stations, and other institutions which offer essential services, and should be symbolized using standardized iconography.

A further challenge of the SLD standard is the need to rely on web map server-specific functionality to apply advanced cartographic styling such as hatching, patterned fills, marker lines and the display of continuous data using interpolation over color ramps, and more.

What is wetransform working towards?

Portrayal recommendations vary widely across the data specification documents of all themes, and often contain unusable SLD code examples, however many of the descriptions contain adequate information to create working SLDs. Many SLDs are based on required attributes, such as geometry, and lend themselves to generic implementation. We are currently building an extensive library of INSPIRE compliant SLDs across all 34 Annex themes. In the future, we hope to develop functionality which will provide end-users with more fine-grained control of the attributes symbolized.

(more)

Tradition would have it that we release a version of hale studio right in time of the INSPIRE conference. The new release 3.4.1 is a bug fix release that addresss frequently-reported issues such as:

  • Fixed problem with GeoServer App-Schema export configuration dialog on Windows
  • Updated cached GML XSD to version 3.2.2
  • Loading an Excel lookup table multiple times no longer causes an error
  • Fixed file name problem when partitioning by feature type in a GML export
  • Fixed problem that prevented partitioning by feature type when transforming external data or with CLI
  • Fixed project validation issue for arrays of numbers

The whole list is available in the changelog.

Download the latest version and send us your feedback:

A 3.5.0 release is also on its way, which brings some changes to the underlying platform as well as a long list of new features.

Thanks to our customers for funding this work on the 25th release of hale studio!

Tradition would have it that we release a version of hale studio right in time of the INSPIRE conference. The new release 3.4.1 is a bug fix release that addresss frequently-reported issues such as:

  • Fixed problem with GeoServer App-Schema export configuration dialog on Windows
  • Updated cached GML XSD to version 3.2.2
  • Loading an Excel lookup table multiple times no longer causes an error
  • Fixed file name problem when partitioning by feature type in a GML export
  • Fixed problem that prevented partitioning by feature type when transforming external data or with CLI
  • Fixed project validation issue for arrays of numbers

The whole list is available in the changelog.

Download the latest version and send us your feedback:

A 3.5.0 release is also on its way, which brings some changes to the underlying platform as well as a long list of new features.

Thanks to our customers for funding this work on the 25th release of hale studio!

(more)

We have now changed our release cycles so that hale studio and hale connect releases happen in quick succession - first hale studio, then hale connect. In this way we ensure that all capabilities you can use in hale studio also work in hale connect. This latest version of hale connect has been rolled out to all public cloud and private cloud instances and includes the following updates:

  • Support for external datasets metadata sources such as Catalogue Services or Portals
  • Support for dataset attachments (such as PDFs, Textures and GeoTIFFs or other Raster data sets)
  • A New GetFeatureInfo client in the WMS map preview
  • A New Feature Explorer Tool specifically designed for object-oriented and linked data

To try out the new features, head over to www.haleconnect.com and either log in with your existing account or create a new (30-day trial) account.

We have now changed our release cycles so that hale studio and hale connect releases happen in quick succession - first hale studio, then hale connect. In this way we ensure that all capabilities you can use in hale studio also work in hale connect. This latest version of hale connect has been rolled out to all public cloud and private cloud instances and includes the following updates:

  • Support for external datasets metadata sources such as Catalogue Services or Portals
  • Support for dataset attachments (such as PDFs, Textures and GeoTIFFs or other Raster data sets)
  • A New GetFeatureInfo client in the WMS map preview
  • A New Feature Explorer Tool specifically designed for object-oriented and linked data

To try out the new features, head over to www.haleconnect.com and either log in with your existing account or create a new (30-day trial) account.

Support for external metadata sources

hale connect now supports the direct re-use of your existing metadata files. For theme managers, these options are configurable in the metadata section of your theme:

  • Select ‘Republish existing metadata’ to upload your XML or XSD during data set creation
  • Select ‘Link to existing metadata’ to provide a URL pointing to dataset metadata

This option you have selected appears in the metadata step of dataset creation. More information on metadata workflows is available from a recent tutorial.

Addign a link to an existing dataset metadata resource

Support for dataset attachments

hale connect 1.9.0 makes it possible to reference file attachments from uploaded or transformed data sets.

To upload attachments, navigate to the Files section of your data set and click the ‘Upload attachments’ button.

To reference the uploaded attachments, your GML source data needs to include the following expression as the value for the attribute which references the attachment: attachment:///<filename>. The filename of the attachment must be identical to the filename in the GML. When the dataset is published, the expression is transformed into a publicly available link to the uploaded attachment file.

Adding attachments to a dataset

Much Linked Data, as well as Open Standards Data, uses rich object-oriented models, with many explicit and implicit references between objects (or as the GIS community calls them, features). Such references are hard to navigate and use in a classical, layers-based GIS. We have thus developed a specific client to explore such data sets.

The Feature Explorer can be accessed via the GetFeatureInfo client on the WMS map preview for your published view services. The Feature Explorer can be used to explore GML that contains complex features and links to related features. INSPIRE compliant GML often contains links to related features, or codelists, which provide additional information about the feature.

To access the Feature Explorer, click on the ‘show Details’ button in the HTML view of GetFeatureInfo client. The Feature Explorer opens in a new tab which displays the attributes associated with the selected feature. Click on any link to further explore the attributes or related features. A ‘+’ button appears to the right of attributes which contain additional levels of nesting.

The FeatureExplorer component with link to codelists, attachments, and related resources and objects

GetFeatureInfo added to WMS Map Preview

GetFeatureInfo is an optional operation which allows users of your view services to query your WMS layers. The GetFeatureInfo client is only available for WMS layers which have been configured to support the GetFeatureInfo operation.

As a theme manager, you can activate GetFeatureInfo for your WMS in the View Services sections of the associated theme. To access the GetFeatureInfo client, click the Map view link in the View Services section of your dataset. Click on any feature in the map preview to view attributes for the selected feature. The GetFeatureInfo client allows you to select the feature layer you are viewing and the display format (HTML, plain text or XML).

Improved GetFeatureInfo and Tool in the Map Preview

(more)

Spring is here and so is the latest release of hale studio. The new release 3.4.0 includes the addition of several, new, third-party plug-ins, new features, as well as numerous bug fixes:

  • Support for isolated workspaces in Geoserver App-Schema plugin
  • XtraServer configuration plugin
  • The alignment merger tool
  • View tasks and messages associated with alignment cells
  • Split GML output by feature type
  • Import Groovy snippets for use in transformation scripts
  • Preset for AAA/NAS XML schema
  • CLI option to output statistics and define custom success conditions

The whole list is available in the changelog.

Download the latest version and send us your feedback:


Spring is here and so is the latest release of hale studio. The new release 3.4.0 includes the addition of several, new, third-party plug-ins, new features, as well as numerous bug fixes:

  • Support for isolated workspaces in Geoserver App-Schema plugin
  • XtraServer configuration plugin
  • The alignment merger tool
  • View tasks and messages associated with alignment cells
  • Split GML output by feature type
  • Import Groovy snippets for use in transformation scripts
  • Preset for AAA/NAS XML schema
  • CLI option to output statistics and define custom success conditions

The whole list is available in the changelog.

Download the latest version and send us your feedback:


Support for isolated workspaces in Geoserver app-schema plugin

The app-schema plugin developed at GeoSolutions now comes with support for GeoServer’s isolated workspaces feature. Isolated workspaces allow service providers to restrict access to OWS layers through virtual services. A virtual service exists for each GeoServer workspace and publishes only those layers available on the associated workspace. Once a workspace is set to isolated, the contained layers are no longer visible or queryable by global services. The contents of an isolated workspace are accessible only via the associated virtual service. This functionality is useful for service providers who want to share specific services with different clients.

Thanks to the GeoSolutions team, specifically to Stefano Costa and Nuno Oliveira, for this contribution!


XtraServer configuration plug-in

XtraServer is a product of interactive instruments GmbH. It is a suite of implementations of various OGC service specifications, e.g. Web Feature Service (WFS) and Web Map Service (WMS). XtraServer services can be based on any application schema according to the Geography Markup Language (GML). For this, a mapping from the GML application schema to the table structure of the underlying database is to be provided in the configuration of the service. The mapping language of XtraServer is very flexible and can virtually map all GML application schemas to heavily deviating database schemas. For this reason, mappings can be quite complex.

The purpose of this plugin is to transform the XtraServer mappings to hale alignments (via Import) and generate a new XtraServer mapping file easily (via Export).

Thanks to interactive instruments, Jon Herrmann, and Andreas Zahnen for this contribution!


The Alignment Merger

Declarative Mappings, which we call Alignments, lend themselves to be re-used. One potential area of re-use is if you have one alignment that maps from A to B and another one that maps from B to C is that you could combine them into a single alignment from A to C. This is exactly what the Alignment Merger command-line component does - it allows you to merge two alignments that have a shared schema into one. As an example, say you have a mapping from a database to a national standard, and one from that national standard to INSPIRE. Now you can directly create a mapping from your database to INSPIRE, without much extra work!

The Alignment Merger will perform as many steps as possible automatically, but will sometimes require manual input from you. For this purpose, the Alignment Merger generates Tasks (see next new feature).

Thanks to the Implementierungspartnerschaft AAA-Dienste for funding this work.

Viewing tasks and messages associated with alignment cells

With the release of 3.4.0, users are able to view and manage tasks that are created by the alignment merger process. This functionality allows users to either dismiss tasks or edit cells directly before transformation.


Allow to split GML output by feature type

hale studio now supports the option to split GML by feature type during the export of a GML feature collection. This new option is helpful for users who want to reduce their file size or who need to work with GML files containing a single feature type.


Groovy snippets as re-useable resoruces

Now you can import Groovy scripts to your transformation project. Using Groovy snippets allows you to keep extensive logic in external files and to easily reuse them across different transformation scripts. You can reference a specific Groovy snippet by its identifier that you set when importing the snippet.


Preset for AAA XML schema

The list of presets for source and target schemas has been extended: The newest addition is the AAA (NAS) XML Schema 6.0.1.


CLI option to output statistics and define custom success conditions

Users performing transformation of source data using the command line interface in hale studio are now able to set customized success conditions through use of a Groovy script which is evaluated against the transformation summary. Success criteria included in an evaluation script might include: an XML schema validation with no errors, or that a certain number of objects were created.

Thanks to the Landesamt für Vermessung und Geobasisinformation Rheinland-Pfalz for funding this work.

(more)