Agree on encoding rules

[fhb1990]

There is interest in the Netherlands to deliver INSPIRE data in Geopackage format. In order to publish INSPIRE data with Geopackage, one needs to publish their encoding rules from UML to GPKG. We have been looking at using this effort as a base for the encoding rules.

However, publishing INSPIRE data with GPKG only makes sense if everybody uses the same encoding rules, so the data becomes interoperable. Of course, if everybody uses and publishes their own encoding rules, we could still transform data between all these different encodings, but this is not desirable. Therefore throughout Europe we should agree on a set of encoding rules such that everyone publishes INSPIRE data in GPKG in the same manner. This would require some sort of centralized effort to agree on these rules.

[heidivanparys]

At a preparatory meeting for the 63rd MIG-T meeting, it was discussed whether a theme-by-theme approach may be the best way forward, see also the presentation.

At a preparatory meeting earlier this week, it was pointed that also datasets for the same theme may be very different from country to country, so different model transformations may be used to achieve a good result. One solution could be to make heavily use of the relational database functionality to create views on tables. So different countries may have different tables (e.g. because different properties are always void, etc.), but would have (some of) the same views definitions. So these "INSPIRE"-views would make sure there is interoperability and Geopackages from different countries can be easily combined, whereas the tables, containing only information that is different for each feature, could be used in other types of analyses, where only data from one country is needed and should be visualised appropriately in a desktop GIS.

Ideally, those view definitions should be treated as common INSPIRE resources (as the GML application schemas are).

@thorsten-reitz Please add to this discussion where needed.

[alexanderkotsev]

As just presented by @heidivanparys during the 64th MIG-T meeting, the idea for DB views is appealing. Would it be an idea to start from the conceptual models and create empty shells for the different data models that can then be filled with the actual substance (as done by the GMLAS OGR/GDAL driver). Clearly, there will be issues related with the fact that the models are often abstract and many implementation choices have to be made but still might be a starting point.