should we use CityGML LandUse or INSPIRE PLU?

[VladimirAlexiev]

@rob-metalinkage @avillar @pzaborowski @FrancescaNoardo, cc @nataschake

CityGML defines a LandUse class:
https://docs.ogc.org/is/21-006r2/21-006r2.html#landuse-section
https://docs.ogc.org/is/20-010/20-010.html#landuse-uml
https://docs.ogc.org/is/20-010/20-010.html#toc55
But it is fairly modest:

• class: specific type [0..1]
• function: intended use [0..*]
• usage: actual use [0..*]

In contrast, INSPIRE PLU defines quite a lot more things:

• docs: https://inspire-mif.github.io/technical-guidelines/data/lu/dataspecification_lu.html (or https://inspire-mif.github.io/technical-guidelines/data/lu/dataspecification_lu.pdf)
• UML: https://inspire-mif.github.io/uml-models/approved/html/index.htm?guid=7B3F6C7A-BB36-4310-A6E9-3E8C242E1AB7
• XSD: https://inspire.ec.europa.eu/schemas/plu/4.0/PlannedLandUse.xsd, https://inspire.ec.europa.eu/schemas/lunom/4.0/LandUseNomenclature.xsd
• OWL (converted by Portelle): saved to https://github.com/Accord-Project/Tegel/tree/main/inspire-plu/ontology

[rob-metalinkage]

Just a reminder about the nature of the various information models and the need to find ways to deal with overlaps and differences, rather than "choose one".

FG-JSON is effective an abstract container providing a soft-typing mechanism ("featureType") and a couple of canonical geo- related first class properties to extend the popular (but limited) GeoJSON to many real-world geometry cases (not just low-fidelity map visualisation).

INSPIRE is a "lowest common denominator" version of many different EU domain data models - so PLU is going to be a good basis but nowhere near complete against all the various EU member state needs (which we would expect each EU state's "native" data models to be designed to support) - it's just the common elements really.

CityGML is a "cityscape" morphology view - just the shapes of things at different levels of details

BIM/IFC is a structural design view - what building components made of what materials in what relative positions to a local coordinate system - and has many sub-variants with many different vocabularies - and no central control over form or semantics of these (a couple of shared lists in play, but large and hard to see how stable)

And finally, there will be the information model derived from the regulations - which may or may not match elements of any of these. (this is the "ACCORD ontology" ? If not, help me understand what the artefacts here are)

The advantage of FG-JSON is it matches a defined API model for access, and doesnt over-define any domain semantics. So its a blank slate we can build a range of different data models on top of ("featureTypes"). We can expect some attempts to deliver INSPIRE through OGC API, since it was regulated to use the previous OGC access API (Web Feature Service 2.0 ) and WFS 3.0 is now "OGC API-Features" with native GeoJSON support.

So some short term actions ( IMHO ):

1. is to try to track down who, if anyone, is investing in INSPIRE PLU -> OGC API-Features and try to get a copy of their "Feature Type" definition - i.e. JSON schema. Its possible, but unlikely, they will have a JSON-LD binding to some ontology, but if they do we should examine that.

2. Set up "building blocks" to collate and validate examples for a PLU-JSON Feature Type (either adopted or developed)

3. Set up one (or more) building blocks as profiles of the PLU-JSON to develop and test candidate mappings to target ontologies.

4. Identify (and register in building block repositories) test examples of PLU data matching the ACCORD and/or CHEK Use Cases

5. Extract a PLU ontology from the INSPIRE UML (if not available from step 1) and use this do the "semantic uplift" via JSON and JSON-LD bindings, using the building blocks test harness.

We can repeat this methodology for CityGML and one or more BIM/IFC flavours, then...

6. Set up transforms from each source to the target model required for reasoning over regulations (ACCORD?)

(note we could also set up building blocks for ACCORD data model schema and API specifications if required, but not sure if that is in scope - certainly keen to explore modular re-usable API building blocks for semantic applications and see if we have overlap with OGC scope!)

7. Demonstrate a reasoning application that exercises the transformation pathways designed and tested against the specification components (i.e. "building blocks" - as in our new approach specifications are always designed to be extended and refined !)

This is quite a lot of "moving parts" - but hopefully broken into unit-testable components that can be re-used in different applications. I may have missed some, or we could break some into smaller pieces.

There are some meta- models that may be relevant for reasoning - and we should explore GeoSPARQL 1.3 extension use cases if relevant

For example - there is the "topo-feature" model [1] that extends FG-JSON to support topology relationships between features. This may be relevant for regulations - if for example they explicit reference boundary lines between 2D objects or shared faces between 3D objects, or points on any object.

The Topo-Feature Building Block is a good example to explore - since it addresses both potential GeoSPARQL update issues and has a set of SHACL rules that extend schema (or OWL) expressivity to define requirements for logical consistency for self-contained collections of features. Its also the foundation for an upstream application.