search

ogcincubator / cityrdf

0 stars 0 forks source link

CityRDF Scope of Work #1

Open VladimirAlexiev opened 2 months ago

VladimirAlexiev commented 2 months ago

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: https://github.com/w3c/json-ld-syntax/issues/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.
  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)
nataschake commented 2 months ago

Additional links:

VladimirAlexiev commented 2 months ago

@nataschake Please capture all links that were shared, eg

Relevant refs from above doc: