News > hale studio

We want to make 2019 the best year ever for the users of our software, and here’s the first contribution towards this: we’ve just released hale studio 3.5.0!

This version brings several changes you need to know about:

  1. hale studio now uses Eclipse Photon, which improves performance by up to 100% and removes several issues on non-windows platforms such as low performance on Linux with GTK 3.18 and start-up issues on macOS
  2. The hale pro plug-ins are now distributed through an update site. This also removed the error messages related to drop-in plug-ins.
  3. The GeoServer plug-in is not anymore part of the default distribution and needs to be installed through an update site.

This enables independent update cycles of the plug-in. It also realizes a clearer separation of concerns – the plug-in will now be maintained and supported by GeoSolutions.

Installing Geoserver and Pro Plug-Ins

You can find instructions on how to install plug-ins from updates sites here. Please note that for the Pro Plug-Ins you still need a license. These licenses are provided to all customers of wetransform who have a support contract.

Important note for Windows users

In case you experience problems with hale studio after upgrading from a previous version (e.g. a missing menu bar or other UI glitches), please make sure to delete or rename the workspace folder HALE in %APPDATA%\wetransform as this folder may contain data incompatible with the new Photon client platform.

Deegree Workspace configuration

A bit like the Geoserver app-schema and Xtraserver configuration, it is now also possible to generate deegree workspace configurations from hale studio alignments. This feature is only available through the user interface, not through the command line interface. Its development was funded by the Landesvermessung und Geobasisinformation Brandenburg.

Partition output by spatial extent

The GML/XML writer in hale studio already supported several partitioning modes, e.g. by Feature Type, or simply by feature count. We’ve now added support to partition output by spatial extent, using either a custom or a standard tile grid. The development of this feature was supported by swisstopo.

Other changes and fixes

  • Improved Xtraserver export
  • Migration support for join conditions and context filters
  • Support for alignments with inline transformations in headless mode
  • Summary in transformation reports
  • Support for matching shortened Shapefile properties
  • Upgraded Groovy to 2.4
  • Upgraded PostgreSQL driver to 42.2.4, PostGIS driver to 2.2.1
  • Fixed file names when partitioning by feature type in a GML export
  • Improved performance for inline transformations where inlined transformation contains Groovy scripts
  • Prevent change of project resources paths if project is exported to hale connect
  • Prevent removal of existing source data when loading additional source data
  • Allow loading hale schema definition file even if constraint type can’t be recreated

The complete changelog is available here.

Plans for 2019

Our current planning includes three more releases for 2019:

  • 3.5.1: Bugfixes that were originally planned for 3.5.0 but didn’t make the cut; might also include updates to the GeoJSON writer to include model transformation rules (then it will become 3.6.0).
  • 4.0.0: Migration to OpenJDK 11, Improved SSL certificate handling, many significant usability improvements
  • 4.1.0: CRS handling improvements, remaining issues after 4.0.0 release

Download hale studio

Download the latest version and send us your feedback:

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

We want to make 2019 the best year ever for the users of our software, and here’s the first contribution towards this: we’ve just released hale studio 3.5.0!

This version brings several changes you need to know about:

  1. hale studio now uses Eclipse Photon, which improves performance by up to 100% and removes several issues on non-windows platforms such as low performance on Linux with GTK 3.18 and start-up issues on macOS
  2. The hale pro plug-ins are now distributed through an update site. This also removed the error messages related to drop-in plug-ins.
  3. The GeoServer plug-in is not anymore part of the default distribution and needs to be installed through an update site.

This enables independent update cycles of the plug-in. It also realizes a clearer separation of concerns – the plug-in will now be maintained and supported by GeoSolutions.

Installing Geoserver and Pro Plug-Ins

You can find instructions on how to install plug-ins from updates sites here. Please note that for the Pro Plug-Ins you still need a license. These licenses are provided to all customers of wetransform who have a support contract.

Important note for Windows users

In case you experience problems with hale studio after upgrading from a previous version (e.g. a missing menu bar or other UI glitches), please make sure to delete or rename the workspace folder HALE in %APPDATA%\wetransform as this folder may contain data incompatible with the new Photon client platform.

Deegree Workspace configuration

A bit like the Geoserver app-schema and Xtraserver configuration, it is now also possible to generate deegree workspace configurations from hale studio alignments. This feature is only available through the user interface, not through the command line interface. Its development was funded by the Landesvermessung und Geobasisinformation Brandenburg.

Partition output by spatial extent

The GML/XML writer in hale studio already supported several partitioning modes, e.g. by Feature Type, or simply by feature count. We’ve now added support to partition output by spatial extent, using either a custom or a standard tile grid. The development of this feature was supported by swisstopo.

Other changes and fixes

  • Improved Xtraserver export
  • Migration support for join conditions and context filters
  • Support for alignments with inline transformations in headless mode
  • Summary in transformation reports
  • Support for matching shortened Shapefile properties
  • Upgraded Groovy to 2.4
  • Upgraded PostgreSQL driver to 42.2.4, PostGIS driver to 2.2.1
  • Fixed file names when partitioning by feature type in a GML export
  • Improved performance for inline transformations where inlined transformation contains Groovy scripts
  • Prevent change of project resources paths if project is exported to hale connect
  • Prevent removal of existing source data when loading additional source data
  • Allow loading hale schema definition file even if constraint type can’t be recreated

The complete changelog is available here.

Plans for 2019

Our current planning includes three more releases for 2019:

  • 3.5.1: Bugfixes that were originally planned for 3.5.0 but didn’t make the cut; might also include updates to the GeoJSON writer to include model transformation rules (then it will become 3.6.0).
  • 4.0.0: Migration to OpenJDK 11, Improved SSL certificate handling, many significant usability improvements
  • 4.1.0: CRS handling improvements, remaining issues after 4.0.0 release

Download hale studio

Download the latest version and send us your feedback:

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

(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)

INSPIRE is not the only open standard for spatial information in Europe, obviously. In Germany, a new standard has been made mandatory in several states in the past year. This standard is for all kinds of planning data, ranging from regional plans to land development plans. The standard is called XPlanung, with the current version of the encoding being called XPlanGML 5.1, and it is mandatory for all companies submitting plans, and for all municipalities publishing plans.

There are several challenges when creating compliant plans, among them the fact that many plans are still only available as scans in PDF, TIFF or PNG format. Actual geodata is then usually limited to a few attributes and a polygon that describes the perimeter of the plan area.

One approach that the community around XPlanung has discussed in detail is to align INSPIRE Planned and Existing Land Use to XPlanung (and vice versa). This alignment was described in the form of a 218-page document. On that base, when you implement one, you can get the other standard for free. However, the length of that document already gives an indication about the complexity of the transformation. This complexity stems both from the size of the XPlanung standard, which covers all types of spatial plans, and from the numerous codelists employed in the source and target models.

For this article, we will only investigate how to map the most common type of plan, a land development plan, to INSPIRE Planned Land Use. In XPlanung, such plans are called BP_Plan. One BP_Plan can have multiple areas of validity, each of which is stored in an object called BP_Bereich.

INSPIRE is not the only open standard for spatial information in Europe, obviously. In Germany, a new standard has been made mandatory in several states in the past year. This standard is for all kinds of planning data, ranging from regional plans to land development plans. The standard is called XPlanung, with the current version of the encoding being called XPlanGML 5.1, and it is mandatory for all companies submitting plans, and for all municipalities publishing plans.

There are several challenges when creating compliant plans, among them the fact that many plans are still only available as scans in PDF, TIFF or PNG format. Actual geodata is then usually limited to a few attributes and a polygon that describes the perimeter of the plan area.

One approach that the community around XPlanung has discussed in detail is to align INSPIRE Planned and Existing Land Use to XPlanung (and vice versa). This alignment was described in the form of a 218-page document. On that base, when you implement one, you can get the other standard for free. However, the length of that document already gives an indication about the complexity of the transformation. This complexity stems both from the size of the XPlanung standard, which covers all types of spatial plans, and from the numerous codelists employed in the source and target models.

For this article, we will only investigate how to map the most common type of plan, a land development plan, to INSPIRE Planned Land Use. In XPlanung, such plans are called BP_Plan. One BP_Plan can have multiple areas of validity, each of which is stored in an object called BP_Bereich.

Type relationships to map XPlanung to INSPIRE

The basic structure in the INSPIRE model is easy enough: There is a SpatialPlan as the main feature type that has a set of OfficialDocumentation objects linked to it that provide legal and other information. We will thus first create the SpatialPlan, and then create all the OfficialDocumentation objects.

BP_Plan and BP_Bereich joined to SpatialPlan

In this type-relationship, we join the types BP_Plan and BP_Bereich based on the following conditions:

BP_Plan.id = BP_Bereich.gehoertZuPlan.href

Please note that hale studio automatically matches href anchors to gml:ids disregarding the # if present.

After doing so, the main information we can map is the set of dates that are present in the source type. There are 13 different date values available in BP_Plan, which we all map to ordinance. For this purpose, we create an instance context for each of the source dates, such as anderungenBisDatum. We then simply rename the source date to ordinanceDate, and assign the name of the source attribute as the ordinanceReference.

We also add references to different types of officialDocuments. In particular, if the source data has a rasterBasis, texte and/or begruendungsTexte, we point to that by renaming that value to officialDocument.href. The other mappings are straightforward. We directly re-use the gml:id from the source for the target, as well as an INSPIRE localId. name becomes officialTitle, rechtsstand is reclassified to processStepGeneral, and nummer becomes alternativeTitle.

BP_Plan Groovy-retyped to OfficialDocumentation

With the main SpatialPlan object having been created, we now need to create OfficialDocumentation objects for various cases. The first is that BP_Plan can contain multiple externeReferenz references. For each of these, we create a OfficialDocumentation object. To do that, we use a Groovy Retype with this small script:



What this script does is to emit an object that contains an ID created in a reproducible manner - using the URL of the reference as input string to generate a UUID.

We then assign the remaining required values to the created objects, such as the INSPIRE Identifier namespace.

BP_Bereich retyped to OfficialDocumentation

The feature type BP_Bereich can also contain references to various documents. We thus retype BP_Bereich to OfficialDocumentation and use the information from BP_Bereich in a straightforward mapping:

Transform XPlanGML BP_Bereich to INSPIRE OfficialDocumentation

Throughout these mappings you will note the use of a log of Assign (Bound) functions. These assign a constant value to the target if the source attribute is present for a given transformed object.

BP_TextAbschnitt retyped to OfficialDocumentation

Finally, A BP_Plan can also contain explicit structured text objects. We also want to bring these BP_TextAbschnitt over to OfficialDocumentation and retype them as well. Much like before, the actual mapping of the properties below is straightforward and only requires Renames, Assigns and a Assign (Bound) function:

Transform XPlanGML BP_TextAbschnitt to INSPIRE OfficialDocumentation

Exporting XPlanGML and conclusion

To export the transformed INSPIRE GML, you do not need to do anything special. You can just use the normal “Export Transformed Data” option.

It is also possible to export XPlanGML from hale studio. For this, you need to create custom data export based on the generic XML writer. This is easily done in just a minute following these steps:

  1. Go to File –> Export –> Create Custom Data Export…
  2. Pick “XML (Custom Root Element)” and click “Next”
  3. Give your custom export configuration a name (without spaces, e.g. xplangml_51) and a description
  4. Choose the correct XML root element; here, this will be XPlanAuszug, and click “Next”.
  5. Choose other settings such as formatted number output, CRS handling and pretty printing, and click “Finish”. You can now export source or transformed data as XPlanGML.

The transformation project is available via haleconnect.com. You can either download it directly from the web interface or in hale studio. In both cases, you need a (free) haleconnect account.

We will continue to build out this alignment and create others for XPlanung and INSPIRE. Let us know if you have any input or would like to get engaged in this activity!

Happy transforming!

(more)

It’s Thursday, or as we at wetransform (thanks to the influence of a certain Venezuelan on the team) call it, Juernes!

In this fourth installment of the Groovy Scripting week, we will tackle another non-trivial case: Building a complete network with nodes and links when your only input data was a bunch of spaghetti lines. This actually requires three scripts. It also shows in detail how to use priorities and other advanced features.

Like the previous posts, note that this article assumes you have working knowledge of hale studio and know the terminology.

In many projects, we did not receive a fully consistent set of Nodes and Links from customers to create a complete Network, or there were no Nodes available at all.

These three snippets extract the first and last Coordinates from each Link (LineString/Curve) and then set up the Node objects, and then create bidirectional references.

Collect Nodes and connected Segment IDs

This is a simple Groovy Retype function that uses the links as a source. The target does not matter, since no target objects are emitted. In this example, the segments are called vaarwegvakken, and the IDs of these segments are stored in the field vwk_id. This function needs to be executed first and should thus have the highest execution priority.

This is the full script:

It’s Thursday, or as we at wetransform (thanks to the influence of a certain Venezuelan on the team) call it, Juernes!

In this fourth installment of the Groovy Scripting week, we will tackle another non-trivial case: Building a complete network with nodes and links when your only input data was a bunch of spaghetti lines. This actually requires three scripts. It also shows in detail how to use priorities and other advanced features.

Like the previous posts, note that this article assumes you have working knowledge of hale studio and know the terminology.

In many projects, we did not receive a fully consistent set of Nodes and Links from customers to create a complete Network, or there were no Nodes available at all.

These three snippets extract the first and last Coordinates from each Link (LineString/Curve) and then set up the Node objects, and then create bidirectional references.

Collect Nodes and connected Segment IDs

This is a simple Groovy Retype function that uses the links as a source. The target does not matter, since no target objects are emitted. In this example, the segments are called vaarwegvakken, and the IDs of these segments are stored in the field vwk_id. This function needs to be executed first and should thus have the highest execution priority.

This is the full script:



You can download this script here.

This snippet is used in a Groovy Create function that has the Node type as a target. This function has to be executed second and needs to have the higher execution priority.



This script also shows how to create a geometry from a coordinate, using a specific coordinate Reference system.

You can download the script here.

In the final step, we add the references from the Links to the nodes created before, so that we have a fully navigable graph in the transport network. This script is inside a normal Groovy Function that has the domain ID of source as the source property and either the startNode or endNode property of the Link as the target property. The surrounding type transformation needs to have a normal execution priority so that it runs after the two other functions.



You can download this script here.

Happy transforming!

(more)

This is the third time to get “Groovy” this week! Today, we will look into how we can simplify Multi-Geometries to simple geometries using a specific script. This is often necessary when the target data model only allows simple geometries, but we can actually have composite and multi-geometries (MultiLineString, MultiPolygon) in the source data.

Like the previous posts, note that this article assumes you have working knowledge of hale studio and know the terminology.

Wednesday’s Script: Create LineStrings from MultiLineStrings (Johanna)

This Groovy Script was developed to aggregate MultiLineString geometries and convert them to LineStrings.

Background: This script was developed to process the 2018 HY-P Swisstopo data. A merge on the feature type level necessitated the use of aggregation to obtain one LineString per feature. The script below was used in a Greedy Groovy script function on the geometry property.

This script also contains a lot of great logging examples!

This is the full script:

This is the third time to get “Groovy” this week! Today, we will look into how we can simplify Multi-Geometries to simple geometries using a specific script. This is often necessary when the target data model only allows simple geometries, but we can actually have composite and multi-geometries (MultiLineString, MultiPolygon) in the source data.

Like the previous posts, note that this article assumes you have working knowledge of hale studio and know the terminology.

Wednesday’s Script: Create LineStrings from MultiLineStrings (Johanna)

This Groovy Script was developed to aggregate MultiLineString geometries and convert them to LineStrings.

Background: This script was developed to process the 2018 HY-P Swisstopo data. A merge on the feature type level necessitated the use of aggregation to obtain one LineString per feature. The script below was used in a Greedy Groovy script function on the geometry property.

This script also contains a lot of great logging examples!

This is the full script:



You can download this script here and import it in hale studio as a Groovy snippet by going to File -> Import -> Groovy Snippet. It assumes a certain geometry attribute name (the_geom) that you might have to change.

Happy transforming!

(more)