News > Interoperability

We’ve brought in more features over the previous month to make your experience with hale»connect even better! Here’s what’s new:

Raster data publishing

hale»connect now supports the upload and publishing of .PNG and .GeoTIFF raster files. This enables you to include your raster data while publishing XPlanung and INSPIRE Land Use data. You can find this option in the “View Services” section in themes. Check out the new raster workflow document in our help section.

New Map View

hale»connect has a new map view based on Open Street Map and Leaflet. You can add your own WMS base map via the layer widget. You can also configure a default basemap configuration for your organization in the organization settings. Check out the documentation sections for more information.

Updated Map View
Map 1: INSPIRE Protected Sites in Germany

Deactivate Users

Administrators can now deactivate and reactivate users. Learn more here.

Autofill rule to populate dataset name

In the metadata section of a theme, users can now add an autofill rule to populate the dataset name. This enables users to select a dataset attribute, or other value, to generate the dataset name. Check out the metadata configuration option here.

Include attachments in atom feed

Haleconnect offers a new setting in the download services section of a theme. The new toggle switch “Include attachment links in Predefined Dataset download services” enables users to download attachments uploaded with their dataset directly from the atom feed. The documentation for this feature can be found here.

Attachment handling

There are now multiple ways to upload attachments on haleconnect. For customers interested in uploading XPlanung data which includes attachments, it is now possible to upload attachment during dataset creation. More information on this update can be found here.

If you have any questions, comments or concerns, don’t hesitate to contact us at info@wetransform.to

We’ve brought in more features over the previous month to make your experience with hale»connect even better! Here’s what’s new:

Raster data publishing

hale»connect now supports the upload and publishing of .PNG and .GeoTIFF raster files. This enables you to include your raster data while publishing XPlanung and INSPIRE Land Use data. You can find this option in the “View Services” section in themes. Check out the new raster workflow document in our help section.

New Map View

hale»connect has a new map view based on Open Street Map and Leaflet. You can add your own WMS base map via the layer widget. You can also configure a default basemap configuration for your organization in the organization settings. Check out the documentation sections for more information.

Updated Map View
Map 1: INSPIRE Protected Sites in Germany

Deactivate Users

Administrators can now deactivate and reactivate users. Learn more here.

Autofill rule to populate dataset name

In the metadata section of a theme, users can now add an autofill rule to populate the dataset name. This enables users to select a dataset attribute, or other value, to generate the dataset name. Check out the metadata configuration option here.

Include attachments in atom feed

Haleconnect offers a new setting in the download services section of a theme. The new toggle switch “Include attachment links in Predefined Dataset download services” enables users to download attachments uploaded with their dataset directly from the atom feed. The documentation for this feature can be found here.

Attachment handling

There are now multiple ways to upload attachments on haleconnect. For customers interested in uploading XPlanung data which includes attachments, it is now possible to upload attachment during dataset creation. More information on this update can be found here.

If you have any questions, comments or concerns, don’t hesitate to contact us at info@wetransform.to

(more)

Each data format is made with a specific purpose. The data stored in the format, however, may be consumed by a multitude of different applications and users. Since the data format was designed with certain use cases in mind, it may not be well-suited for other functions. As such, it’s important to bridge the gap between a certain format and the needs of end users who want to work with the data.

To enhance data usability, other formats or encodings can be used to complement the default encoding. In the context of INSPIRE, this can be an alternative encoding, i.e. one that fulfills all requirements of the INSPIRE Implementing Rule and thus be used instead of the default encdoing, or it can be an additional encoding.

The goal of such encodings is to act as a link between the default encoding and a use case that is not addressed sufficiently by the default encoding. There are a few questions that must be answered while chosing or developing an encoding, such as:

  • Which kind of themes and use cases are you building the alternative encoding for?
  • What model transformation rules need to be applied to match the conceptual model to the capabilities of the format’s logical model?
  • How can this encoding be implemented?

Thorsten Reitz, CEO of wetransform, presented a webinar that answered these questions. The webinar also presented GeoJSON alternative encodings that are targeted at making INSPIRE data easily usable.

The default encoding for INSPIRE data is complex GML, which is well suited for the interchange of data. Since it has been made with the purpose of interoperability, it does well in terms of providing easy exchange of complex data. Common web applications and web APIs can perform standard operations on data formats that are not nested, however, and have difficulties doing so with nested data formats such as complex GML. According to the MIG Working group, “While INSPIRE data encoded according to the current schemas can be downloaded and viewed, simple use (visualisation, simple joins, visual overlays, spatial search, …) is difficult in standard GIS clients.

The webinar described how the GeoJSON encoding can help you gain maximum value from your INSPIRE data by making the data more compatible with GIS clients. The GeoJSON alternative encoding can be used instead of the nested INSPIRE GML data. GeoJSON is designed from the ground up to easily be consumed by web applications and web service APIs, thus providing for a use case that is not well-suited to INSPIRE GML. The webinar also covered the most common issues faced while trying to create an alternative encoding, the structure of GeoJSON encoding rules and model transformation rules. It mentioned how to measure the success of alternative encoding and looked at whether the GeoJSON alternative encoding succeeded in making INSPIRE data more usable in a specific target environment.

You can find a link to the webinar here.

Each data format is made with a specific purpose. The data stored in the format, however, may be consumed by a multitude of different applications and users. Since the data format was designed with certain use cases in mind, it may not be well-suited for other functions. As such, it’s important to bridge the gap between a certain format and the needs of end users who want to work with the data.

To enhance data usability, other formats or encodings can be used to complement the default encoding. In the context of INSPIRE, this can be an alternative encoding, i.e. one that fulfills all requirements of the INSPIRE Implementing Rule and thus be used instead of the default encdoing, or it can be an additional encoding.

The goal of such encodings is to act as a link between the default encoding and a use case that is not addressed sufficiently by the default encoding. There are a few questions that must be answered while chosing or developing an encoding, such as:

  • Which kind of themes and use cases are you building the alternative encoding for?
  • What model transformation rules need to be applied to match the conceptual model to the capabilities of the format’s logical model?
  • How can this encoding be implemented?

Thorsten Reitz, CEO of wetransform, presented a webinar that answered these questions. The webinar also presented GeoJSON alternative encodings that are targeted at making INSPIRE data easily usable.

The default encoding for INSPIRE data is complex GML, which is well suited for the interchange of data. Since it has been made with the purpose of interoperability, it does well in terms of providing easy exchange of complex data. Common web applications and web APIs can perform standard operations on data formats that are not nested, however, and have difficulties doing so with nested data formats such as complex GML. According to the MIG Working group, “While INSPIRE data encoded according to the current schemas can be downloaded and viewed, simple use (visualisation, simple joins, visual overlays, spatial search, …) is difficult in standard GIS clients.

The webinar described how the GeoJSON encoding can help you gain maximum value from your INSPIRE data by making the data more compatible with GIS clients. The GeoJSON alternative encoding can be used instead of the nested INSPIRE GML data. GeoJSON is designed from the ground up to easily be consumed by web applications and web service APIs, thus providing for a use case that is not well-suited to INSPIRE GML. The webinar also covered the most common issues faced while trying to create an alternative encoding, the structure of GeoJSON encoding rules and model transformation rules. It mentioned how to measure the success of alternative encoding and looked at whether the GeoJSON alternative encoding succeeded in making INSPIRE data more usable in a specific target environment.

You can find a link to the webinar here.

(more)

There’s a lot of data published on hale»connect, and it’s important to us that it looks good to you. For this purpose, we’d like you to have the opportunity to publish Styled Layer Descriptors (SLDs.)

The OGC standard Styled Layer Descriptor (SLD) defines an XML format to encode cartographic rules by which to display features. It reuses the OGC standards Symbology Encoding (SE) and Filter Encoding (FE). 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.

The hale»connect platform enables users to provide their own layer styles, or to leverage our own, extensive library of INSPIRE Styled Layer Descriptors, and growing library of XPlanung SLDs. When you publish data on hale»connect, the data is matched against the hale»connect SLD library. SLDs are then applied if available. A default style layer is applied to all datasets for which a matching style layer does not exist. Alternatively, you can upload your own, valid SLDs. Here’s an example of a fully valid SLD file that is ready to be published:

SLD for shapefile

  <?xml version="1.0" encoding="UTF-8"?>
  <StyledLayerDescriptor
  version="1.1.0"  
  xmlns="http://www.opengis.net/sld"
  xmlns:ogc="http://www.opengis.net/ogc"
  xmlns:se="http://www.opengis.net/se"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:gml="http://www.opengis.net/gml/3.2"
  xmlns:sld="http://www.opengis.net/sld"
  xmlns:ns="http://www.esdi-humboldt.eu/hale/shp/myShapefile"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sldAll.xsd http://www.opengis.net/se http://schemas.opengis.net/se/1.1.0/FeatureStyle.xsd">
  <NamedLayer>
    <se:Name>MyShapefileLayer</se:Name>
    <UserStyle>
      <se:Name>MyStyle</se:Name>
      <se:Title>MyStyle</se:Title>
      <se:FeatureTypeStyle>
        <se:Name>Default Polygon Style</se:Name>  
        <se:FeatureTypeName>ns:myShapefile</se:FeatureTypeName>	  
          <se:Rule>
            <se:Title>Shapefile Polygons</se:Title>
            <se:PolygonSymbolizer>
              <se:Fill>
                <se:SvgParameter name="fill">#78C46E</se:SvgParameter>
                <se:SvgParameter name="fill-opacity">0.5</se:SvgParameter>
              </se:Fill>
              <se:Stroke>
                <se:SvgParameter name="stroke">#38A800</se:SvgParameter>
                <se:SvgParameter name="stroke-width">1.5</se:SvgParameter>
              </se:Stroke>
            </se:PolygonSymbolizer>
          </se:Rule>
          <se:Rule>
            <se:MaxScaleDenominator>40000</se:MaxScaleDenominator>
            <se:TextSymbolizer>
              <se:Label>
                <ogc:PropertyName>ns:name/text()</ogc:PropertyName>
              </se:Label>
              <se:Font>
                <se:SvgParameter name="font-family">Arial</se:SvgParameter>
                <se:SvgParameter name="font-size">14</se:SvgParameter>
                <se:SvgParameter name="font-style">normal</se:SvgParameter>
                <se:SvgParameter name="font-weight">bold</se:SvgParameter>
              </se:Font>
              <se:Halo>
                <se:Radius>3</se:Radius>
                <se:Fill>
                  <se:SvgParameter name="fill">#ffffff</se:SvgParameter>
                </se:Fill>
              </se:Halo>
              <se:Fill>
                <se:SvgParameter name="fill">#38A800</se:SvgParameter>
              </se:Fill>
          </se:TextSymbolizer>          
        </se:Rule>
      </se:FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

Want to learn more about publishing SLDs? We just created an SLD tutorial for users interested in creating their own SLDs for shapefile or GML. You can check it out here.

If you are interested in having us create a custom style for you, please contact support.

There’s a lot of data published on hale»connect, and it’s important to us that it looks good to you. For this purpose, we’d like you to have the opportunity to publish Styled Layer Descriptors (SLDs.)

The OGC standard Styled Layer Descriptor (SLD) defines an XML format to encode cartographic rules by which to display features. It reuses the OGC standards Symbology Encoding (SE) and Filter Encoding (FE). 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.

The hale»connect platform enables users to provide their own layer styles, or to leverage our own, extensive library of INSPIRE Styled Layer Descriptors, and growing library of XPlanung SLDs. When you publish data on hale»connect, the data is matched against the hale»connect SLD library. SLDs are then applied if available. A default style layer is applied to all datasets for which a matching style layer does not exist. Alternatively, you can upload your own, valid SLDs. Here’s an example of a fully valid SLD file that is ready to be published:

SLD for shapefile

  <?xml version="1.0" encoding="UTF-8"?>
  <StyledLayerDescriptor
  version="1.1.0"  
  xmlns="http://www.opengis.net/sld"
  xmlns:ogc="http://www.opengis.net/ogc"
  xmlns:se="http://www.opengis.net/se"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:gml="http://www.opengis.net/gml/3.2"
  xmlns:sld="http://www.opengis.net/sld"
  xmlns:ns="http://www.esdi-humboldt.eu/hale/shp/myShapefile"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sldAll.xsd http://www.opengis.net/se http://schemas.opengis.net/se/1.1.0/FeatureStyle.xsd">
  <NamedLayer>
    <se:Name>MyShapefileLayer</se:Name>
    <UserStyle>
      <se:Name>MyStyle</se:Name>
      <se:Title>MyStyle</se:Title>
      <se:FeatureTypeStyle>
        <se:Name>Default Polygon Style</se:Name>  
        <se:FeatureTypeName>ns:myShapefile</se:FeatureTypeName>	  
          <se:Rule>
            <se:Title>Shapefile Polygons</se:Title>
            <se:PolygonSymbolizer>
              <se:Fill>
                <se:SvgParameter name="fill">#78C46E</se:SvgParameter>
                <se:SvgParameter name="fill-opacity">0.5</se:SvgParameter>
              </se:Fill>
              <se:Stroke>
                <se:SvgParameter name="stroke">#38A800</se:SvgParameter>
                <se:SvgParameter name="stroke-width">1.5</se:SvgParameter>
              </se:Stroke>
            </se:PolygonSymbolizer>
          </se:Rule>
          <se:Rule>
            <se:MaxScaleDenominator>40000</se:MaxScaleDenominator>
            <se:TextSymbolizer>
              <se:Label>
                <ogc:PropertyName>ns:name/text()</ogc:PropertyName>
              </se:Label>
              <se:Font>
                <se:SvgParameter name="font-family">Arial</se:SvgParameter>
                <se:SvgParameter name="font-size">14</se:SvgParameter>
                <se:SvgParameter name="font-style">normal</se:SvgParameter>
                <se:SvgParameter name="font-weight">bold</se:SvgParameter>
              </se:Font>
              <se:Halo>
                <se:Radius>3</se:Radius>
                <se:Fill>
                  <se:SvgParameter name="fill">#ffffff</se:SvgParameter>
                </se:Fill>
              </se:Halo>
              <se:Fill>
                <se:SvgParameter name="fill">#38A800</se:SvgParameter>
              </se:Fill>
          </se:TextSymbolizer>          
        </se:Rule>
      </se:FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

Want to learn more about publishing SLDs? We just created an SLD tutorial for users interested in creating their own SLDs for shapefile or GML. You can check it out here.

If you are interested in having us create a custom style for you, please contact support.

(more)

As we shift to data-driven approaches towards decision-making, location intelligence begins to matter more and more. The effect of geodata encompasses many industries including construction and engineering, energy, insurance and real estate. The interoperability of geodata continues to play a critical part in facilitating information exchange across these industries.

From April 2nd to 4th 2019, the Geodata community came together for Geospatial World Forum. Stakeholders shared the relevance of geodata in different sectors. They presented a 360-degree perspective of the role played by geodata across different industries, including the challenges faced by different organizations and identifying where opportunities for collaboration exist. Specifically, the importance of location intelligence in bridging knowledge gaps and digitizing economies was brought to the forefront.

A recurring theme was that of the intersection of geodata and smart cities. Smart cities provide resilience, situational awareness and decision support. Covering aspects from building schools in the optimal location to provide the access to all citizens, to long-term goals such as containing climate change, smart cities centrally are aimed at improving the quality of life. To create an encompassing smart city from a truly data-driven perspecitve, reliable and well-maintained geodata is a must.

Marino Cavallo, the Head of Research and Innovation at the City of Bologna, spoke of the importance of the link between smart cities and sustainability, and how open geodata can boost citizen participation. The speech also included the example of Bologna to demonstrate how nature-based solutions can promote social cohesion, new enterprises and civic engament. You can find the paper abstract here and the presentation here.

Akshat Bajaj, wetransform’s marketing manager, presented on how an interoperable geodata could allow you to form a concrete basis to meet reporting standards. Achieving easy extensibility in such a situation promotes streamlined shift towards data-based approaches, which forms a reliable launch pad for developing smart city infrastructures. The case study focused on extending an INSPIRE dataset to XML type 2.

It focused on identifying a method to easily extend INSPIRE data to meet e-reporting obligations, the challenges faced, and how they were overcome. Check out the abstract and presentation now!

Would you like to know more about such projects? Feel free to contact us and fully understand how you can extend open data to meet business requirements. If you would like to have a go at it yourself, you can register for a free trial of our product, hale connect, a cost-efficient cloud-based platform that allows you to comply with open standards with minimal efforts.

As we shift to data-driven approaches towards decision-making, location intelligence begins to matter more and more. The effect of geodata encompasses many industries including construction and engineering, energy, insurance and real estate. The interoperability of geodata continues to play a critical part in facilitating information exchange across these industries.

From April 2nd to 4th 2019, the Geodata community came together for Geospatial World Forum. Stakeholders shared the relevance of geodata in different sectors. They presented a 360-degree perspective of the role played by geodata across different industries, including the challenges faced by different organizations and identifying where opportunities for collaboration exist. Specifically, the importance of location intelligence in bridging knowledge gaps and digitizing economies was brought to the forefront.

A recurring theme was that of the intersection of geodata and smart cities. Smart cities provide resilience, situational awareness and decision support. Covering aspects from building schools in the optimal location to provide the access to all citizens, to long-term goals such as containing climate change, smart cities centrally are aimed at improving the quality of life. To create an encompassing smart city from a truly data-driven perspecitve, reliable and well-maintained geodata is a must.

Marino Cavallo, the Head of Research and Innovation at the City of Bologna, spoke of the importance of the link between smart cities and sustainability, and how open geodata can boost citizen participation. The speech also included the example of Bologna to demonstrate how nature-based solutions can promote social cohesion, new enterprises and civic engament. You can find the paper abstract here and the presentation here.

Akshat Bajaj, wetransform’s marketing manager, presented on how an interoperable geodata could allow you to form a concrete basis to meet reporting standards. Achieving easy extensibility in such a situation promotes streamlined shift towards data-based approaches, which forms a reliable launch pad for developing smart city infrastructures. The case study focused on extending an INSPIRE dataset to XML type 2.

It focused on identifying a method to easily extend INSPIRE data to meet e-reporting obligations, the challenges faced, and how they were overcome. Check out the abstract and presentation now!

Would you like to know more about such projects? Feel free to contact us and fully understand how you can extend open data to meet business requirements. If you would like to have a go at it yourself, you can register for a free trial of our product, hale connect, a cost-efficient cloud-based platform that allows you to comply with open standards with minimal efforts.

(more)