GeoJSON encoding of INSPIRE Datasets

This Good Practice (GP) describes a mechanism to create INSPIRE data sets encoded using the GeoJSON encoding standard.

GeoJSON is an open standard format for geospatial data interchange, designed to represent simple geographical features and their non-spatial attributes. It is based on JSON, the JavaScript Object Notation. GeoJSON uses a geographic coordinate reference system, World Geodetic System 1984, and units of decimal degrees. GeoJSON Geometry Objects may be points (which can be used for features like addresses and locations), line strings (e.g. for streets, highways, boundaries), polygons (countries, provinces, tracts of land), and multi-part collections of these types. GeoJSON features are not only used to represent entities of the physical world. For example, mobile routing and navigation apps may describe their service coverage using GeoJSON.

The GeoJSON format has originally been defined by an Internet working group of developers who needed a solution to encode geometries for use in web applications. It has since been formalised by the IETF, a standards organisation which develops specifications concerning the Internet as RFC 7946.

Within INSPIRE, the GeoJSON encoding can be used to encode data from several themes in order to improve data sharing via APIs and the usability of the data in web clients such as ArcMap, QGIS, OpenLayers, Leaflet and in mobile applications.

It can serve as an alternative encoding that can be used instead of the default encoding for simple data, where there is no information loss. In other cases, this GeoJSON encoding may serve as an additional encoding only.

When it is used as alternative encoding, the dataset shall be compliant with the INSPIRE Implementing Rules (IR), and technical compliance will be demonstrated through transformation to the default encoding (GML).

The GeoJSON encoding can be used on core INSPIRE data specifications, or on extensions, and can also be use-case specific. This means that even for one INSPIRE theme, multiple logical schemas could, over time, become available. GeoJSON models related to the different data themes/use cases need be described in the INSPIRE-MIF repository for the GeoJSON encoding.

For any GeoJSON logical schema to be accepted as specific implementation of this GP, the following resources must be created:

• A description of the logical model, its relevance and expected benefits, its implementations and its limitations compared to the default encoding

• A JSON schema

• A formal, executable specification of the UML-to-GeoJSON model transformation or the GML-to-GeoJSON model transformation referencing and conforming to the generic INSPIRE model transformation rules in the INSPIRE-MIF model-transformation-rules repository. These generic INSPIRE model transformation rules are encoding-agnostic and will/may be underpinning the development of different encodings for INSPIRE data. These will in turn be described in their own, encoding-specific INSPIRE-MIF repositories. The gp-GeoJSON-encodings repository is the encoding-specific repository for this GP. The executable specification can be delivered in any form that takes a computer-readable model as input and creates a computer-readable model as output. These specifications can be programs. They need to be documented in such a way that the mapping is human-readable. Examples include an annotated ShapeChange configuration, an XSLT, or a hale studio model transformation.

• A formal, executable model for data transformation that allows to transform a data set encoded as GeoJSON to the default encoding. This can be delivered as an ETL workbench (e.g. hale studio transformation project, FME workbench), as a standalone program or as a service. In all cases, the executable model must be documented in a human-readable form.

INSPIRE component(s)

Data: this GP describes how data falling under any INSPIRE theme can be encoded in GeoJSON format in such a way that the abstract requirements from related specifications are met. The GP relies on INSPIRE code lists, and transformation services.

Note: This document does not describe a formal mechanism to publish data sets as a network service.