ogcincubator / cityrdf

CityRDF

This is a repository for developing an RDF Ontology for CityGML / CityJSON.

cityrdf's Issues

CityRDF Scope of Work

Meeting minutes 30 Apr 2024 with @rob-metalinkage @avillar @nataschake @peterrdf @svilenvarbanov2019

CityRDF Scope of Work

1. CityGML to CityJSON conversions: are they authoritive?
   • Rob: CityJSON has its peculiar geometry representaiton and schema, it's unlike any other (not like GeoJSON).
     It is a complex thing: arrays of vertex coordinates, and another parallel array of their meanings/connectivity.
     So the geometry is "far away" from the features/objects.
   • So CHEK wants to use CityJSON, but will transform it into a different JSON representation
   • Vlado: w3c/json-ld-syntax#425 may be relevant (how to capture geometry as an opaque literal, and "retype" rdf:JSON to geo:geoJSONLiteral?)
   • How much of CityGML is captured by CityJSON? The "best 95%"
   • CityJSON geometries:

"MultiPoint"
"MultiLineString"
"MultiSurface"
"CompositeSurface"
"Solid"
"MultiSolid"
"CompositeSolid"

2. CHECK wants to use with GeoJSON/FG JSON that's much close to RDF (through JSONLD)
   • GeoJSON is not enough for engineering survey applciations, because it uses only WGS 84
   • FG JSON adds various CRS, and even time-dependent coordinates (the land in Australia moves 7cm/year)
3. GeoSPARQL 1.3 is gathering requirements.
   • The idea is for it to be a modular spec, with multiple 3D profiles and features for different purposes
     • Eg see OGC building blocks: https://ogcincubator.github.io/topo-feature/bblock/ogc.geo.topo.features.topo-arc/examples
       with definition; JSON, JSONLD, Turtle conversions; JSONLD context; JSON schema; SHACL shapes.
     • This is "constructive geometry", it's best suited for Survey, which is all based on points.
       To extract some characteristic (eg highest point of that arc, area of some surface), you still need complex functions.
     • BHoM (https://bhom.xyz/ , https://github.com/BHoM) pushes the idea that data models must always come with APIs and reference software implementations.
       And LDAC 2023 presented a first Linked Data approach towards BHoM
     • But there are building blocks that are APIs, i.e. focusing on the software processing of that complex data:
       https://ogcincubator.github.io/bblocks-ogcapi-features/
   • A set of well-known functions for answering 3D questions and transforming between representations
   • Vlado: we should start from:
     • BimSPARQL [@zhangBimSPARQLDomainspecificFunctional2018] in Zotero "Semantic BIM"
     • CHEK and ACCORD checking requirements
     • PostGIS 3D functions https://postgis.net/workshops/postgis-intro/3d.html#d-functions
     • Maybe https://www.3dcitydb.org/3dcitydb/ (does it have an API and function library?)
   • Make reference implementations of these functions!
4. Analyze gaps between CityGML geopmetries (eg CSG, swept volumes, etc) and native implementations
   • Similar to what we discussed with RDF.bg about IFC geometries, maybe we need to express that into simplified geometries (eg TINs):
   • Eg implementations: RDF.bg geometry library, OCC, GlTF
   • We probably need to keep multiple/redundant geometry representations: various LOD, various implementations, building element bounding boxes (eg IFCtoLBD extracts such, emitting pseudo-WKT)
5. CityRDF ontology: start with an automatic UML->OWL conversion by ShapeChange.
   But then customize to:
   • Capture geometries as opaque GML literals ala GeoSPARQL
   • Alejandro: won't be too hard to resolve CityJSON geometries to WKT
   • Vlado: but is WKT on par with GML? I think WKT covers only SF, whereas GML covers a lot more.
     Rob: I don't think WKT is expressive enough.
   • Get rid of ADE classes and props, and abstract classes due to them
6. Craft JSONLD context
7. Craft JSONLD frame to conform to "CityJSON v2" (FG JSON schema for Cities)
8. Round-trip some examples XML->JSON->RDF and back
9. Write a XML->RDF convertor (eg in xsparql, lixr, rml) that does XML->RDF directly, not XML->JSON->RDF
10. Maybe derive/author SHACL shapes for additional structural checking
11. Incorporate LandUse classes/props from:
    • INSPIRE PLU
    • DE XPlanung?
    • LandXML
    • InfraGML
    • 3DCadastres Workshop 2024 and new work group working on Land Use (LADM, 3D LAnd Administration), within FIG (International Federation of Surveyors: standard settings org on global land survey).
    • How about topography, i.e. terrain? (see "Building Height" example below)
12. Development driven by use/test cases (i.e. individual checking requirements)

• Eg Building Height:
  • DE case: they have 2 reference points: ground (eg according to average water level at some NL canal lock: Germans!); building (eg eaves, or top of roof)
  • ES case: in a mountainous city, where the building is partly embedded in the rock, do you measure from street level (front of building), or basement level (back of building)?
    In Norway there's no rule how many basements you can have, so a guy had a cellar, a luxury sunning room, and a car garage on top of each other. (He was "lucky" to build on a steep rocky shore)

13. Logistics: rename ogc/CHEK-profiles to something like ogc/CityRDF, invite the participants (see list on top)