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.