Are simplified data encoded as GeoJson considered INSPIRE compliant?

[hallinpihlatie]

Hi,

As the OGC API Feature has now been accepted as an alternative way to implement an INSPIRE Download service, I'd like to know whether OGC API Feature services that provide data in GeoJson following the rules set out in the MIG activity 2017.2 (links below) are considered to be INSPIRE complaint?

https://github.com/INSPIRE-MIF/2017.2/blob/master/GeoJSON/geojson-encoding-rule.md https://github.com/INSPIRE-MIF/2017.2/blob/master/model-transformations/TransformationRules.md

Or is there an additional procedure required?

This is crucial to know for example when a data provider asks whether they can now replace their WFS services, which are providing harmonised data sets with their new OGC API Features services, providing data sets in GeoJson following these rules.

A confirmation for this would be very helpful eg. @MarcoMinghini , thanks.

Lena

[hallinpihlatie]

Hi JRC, all,

To make my question a bit concrete. Does the simplified INSPIRE models used in the GeoJson encoding have be accepted as Good Practise in order to be officially considered as INSPIRE compliant?

I hope such a procedure isn't necessary, but just checking.

Kind regards, Lena

[KathiSchleidt]

related to this, has some agreement been reached on what the officially accepted separator shall be? I'd analyzed the rules 2 years ago, found an eclectic mix of "." and "" separators. To my understanding, this was due to a change in process once the fact that ESRI SW cannot deal with "." in attribute names. Now revisiting the transformation rules, it seems "." has been generally adopted, but parts of the documentation don't reflect this. In the following, the encoding follows "." while the text implies "": https://github.com/INSPIRE-MIF/2017.2/blob/master/model-transformations/GeneralFlattening.md

Also - to my knowledge OGC API is going towards kebab-case, also not ideal as one cannot directly reuse attribute names as variable names in many programming languages, but should be taken into account here.

[alexanderkotsev]

Thanks @hallinpihlatie for the question. The results of action 2017.2 on the model transformation and GeoJSON encoding are endorsed by the MIG with the closure of sub-group 2017.2. The reason why they are not submitted as a good practice is the limited implementation evidence which is also reflected in the minutes of the 62nd MIG-T meeting. Examples can be provided directly on GitHub. Once the implementation evidence is available, we can initiate the Good Practice procedure and think of the follow up steps like ETS and validation of GeoJSON instances.

[alexanderkotsev]

@KathiSchleidt - if I remember correctly, there was never a definitive decision on the separator. From tests done roughly 2 years ago, there was an issue with pygeoapi and the '.'. Basically, the whole part of the property name after the '.' was removed. Considering that, if we want to ensure good support with different tools, I would go for either kebab or snake case. @thorsten-reitz what do you think?

[KathiSchleidt]

@alexanderkotsev now I'm really confused! To my understanding, the INSPIRE Good Practice for OGC API - Features as an INSPIRE download service is endorsed - does this only pertain to its use as a download service, not towards the encoding? Will there be an additional Good Practice on encoding as indicated in the Evidence section of the OGC API - Features GP? Also - what does this mean for INSPIRE data providers? They can make an OGC API - Features endpoint available via INSPIRE, but cannot provide data?

[alexanderkotsev]

The good practice for OGC API Features as Part 1 of the standard itself is neutral from an encoding point of view. The only req class referring to GeoJSON is optional with a referrence to the work of the 2017.2 sub-group. Regarding the encoding - as said, we need some evidence as done for STA and OAPIF to comply to the rules for GP. Once this is available thus confirming the proposed technical provisions we can go ahead with the proposed approach as a GP.

[thorsten-reitz]

@KathiSchleidt @alexanderkotsev You can provide a compliant download service by using the Feature API (as an alternative toWFS2) with GML encoded payloads. As far as I know, the Feature API is not bound to an encoding as much as that was the case with WFS 2 and GML.

With respect to the additional/alternative encoding work, we've mostly continued working on the model transformation rules and on the GeoPackage encoding, where we did use the underscore where separation was necessary. In a couple of weeks I would be feasible for me to do an editorial pass over the GeoJSON spec. @alexanderkotsev would that be OK?

[KathiSchleidt]

@thorsten-reitz true - XML encoding is defined, that should work To the JSON encoding, when I'd originally reviewed it was an eclectic mix of "" and "." separators, now the MIG encoding rules seem to have been aligned to "." separator - how does this go with the "" rules mentioned?

[thorsten-reitz]

@KathiSchleidt In the GeoPackage work for INSPIRE and END, we've defaulted to using the underscore (and we've also limited attribute name lengths to 31 characters due to some compatibility issues in the Esri world). I'll clarify with the EEA when we can share that work. It's supposed to be completed this month.

[hallinpihlatie]

Thanks @alexanderkotsev So once implementation evidence has been linked to the 2017.2 documents and they have been accepted though the GP procedure, and needed follow up steps (ETS and validation of GeoJSON instances) have been done, there is not a need to further accept theme-specific/data-group specific GeoJSON instances/data models? Or this still an open issue?

There is implementation evidence available. How should one go bring them forward?

[thorsten-reitz]

Hi @KathiSchleidt and @hallinpihlatie , the process we discussed during the work in 2017.2 was that specific data models would still be required for any alternative encoding (be it GeoPackage or GeoJSON or ...), specified along the structure of the Adresses and EMF examples that were made as part of that work.

However, we had also discussed that these models should be developed by the community, and then brought forward as proposals. There is of course a risk that people will develop multiple models for the same theme and encoding, but as far as I understand, the JRC team has been proposing a process to deal with that.

In principle, since each proposed encoding-level model would contain a mapping to the concepetual model which prooves INSPIRE IR compliance, there could indeed be multiple ones, though combining data will be more challenging.

[akuegeler]

@KathiSchleidt, @alexanderkotsev, here's the link to the discussion on the dot as a separator: https://github.com/INSPIRE-MIF/2017.2/issues/89 which was resolved by @thorsten-reitz exchanging the separators from dots to underscores. ...so can we assume that snake_case is the way to go?

[hallinpihlatie]

A few implementations applying the 2017.2 guidelines: Buildings: https://beta-paikkatieto.maanmittauslaitos.fi/inspire-buildings/features/v1/ Addresses: https://beta-paikkatieto.maanmittauslaitos.fi/inspire-addresses/features/v1/. DP, PF, SU and US: https://geo.stat.fi/inspire/

Is this sufficient as implementation evidence to proceed to turn the 2017.2 guidelines into a GP?