ogcincubator / chek-profiles Goto Github PK

@rob-metalinkage @avillar (cc @nataschake)
I looked at some examples and have some questions about SRS representation in GML:

https://github.com/VCityTeam/UD-Sample-data/blob/master/CityGMLv3.0/LYON_1ER_BATI_2009-2018_hotel_de_ville/LYON_1ER_47BATI_2018.gml

• some but not all geometries have srsName. Eg UUID_c3e08e2a-5406-473b-b94b-e09013054651_msl_N65584 doesn't (and it's not nested in any other object to assume that it would "inherit" it from somewhere)
• the ones that have it use srsName="EPSG:3946": but isn't this supposed to be a full URL?

https://github.com/opengeospatial/CityGML3.0-GML-Encoding/blob/main/resources/examples/Building/Building_CityGML3.0_LOD2_with_several_attributes.gml

• srsName="urn:adv:crs:DE_DHDN_3GK4*DE_DHHN92_NH": how's any geospatial software supposed to find the attributes of this SRS to be able to transform the geometry?
• Again, the majority of geometries don't have a srsName
• The first <gml:posList> doesn't even say srsDimension="3" so how's any geospatial software able to parse this properly into triples not pairs?

@avillar @rob-metalinkage @peterrdf (and cc @nataschake)
I'll split this topic from #1 since it's crucial.

https://github.com/ogcincubator/chek-profiles/blob/master/cityjson/twobuildings.city.ttl shows geometries converted to triples (down to individual vertices and individual coordinates).

• I believe that's the wrong way to do geometry. A similar approach is used in IfcOwl (though using lists of blank nodes), and pretty much nobody uses it because it's too complicated.
• The right way is to use GeoSPARQL opaque literals
  • 1.0 supports WKT, GML. For CityGML (XML) source, the best way is to convert to geo:asGML "..."^^geo:gmlLiteral
  • 1.1 also supports KML, GeoJSON. For CityJSON source, the best way is to convert to geo:asGeoJSON "..."^^geo:geoJSONLiteral
• The benefit of GeoSPARQL literals is that semantic repositories handle them specially in geospatial indexes, so you can use fast "magic predicates" for the topological relations (eg sf:Within).

Looking at https://dataset-dl.liris.cnrs.fr/rdf-owl-urban-data-ontologies/Ontologies/CityGML/3.0/core,
I think that CityGML ties up into GeoSPARQL geometries, eg

• core:ImplicitGeometry.relativeGeometry has range gmlowl:AbstractGeometry
• https://schemas.opengis.net/gml/3.2.1/gml_32_geometries.rdf
  shows that gmlowl:AbstractGeometry rdfs:subClassOf geo:Geometry
  (http://www.opengis.net/ont/geosparql#Geometry)

Cheers!

@avillar @rob-metalinkage @peterrdf Here's an initial list of issues from about 20 min inspection of the example json/turtle.

Conventions:

• Change the checkbox state as we go through the bullets
• If you can edit this description, add eventual notes as sub-bullets
• For links to show as code snippets, you need to refer to the specific commit (eg blob/c46b466e036857a719f31ae47c4753637f9ca248 not blob/master).
  As https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet describes, you can copy this link by using ... > Copy permalink (don't copy from the address bar). Let's adopt this convention since it's very convenient to see the snippets

Issues:

• rename this repo from chek-profiles to perhaps CityRDF-examples. I don't think our project controller will look nicely at me working on some other project's repo/stuff. Also, I feel it's prestigious to work on an RDF/OWL rendition of CityGML, but not so on somebody else's project.
• The city:CityJson type is wrong, because the turtle result is NOT json. Maybe rename this type to CityGML or CityData?

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 23 in c46b466

  [] a city:CityJson ;

• #2
  but city:hasVertex is unordered in turtle

  chek-profiles/cityjson/twobuildings.city.ttl

  Lines 44 to 46 in c46b466

  	city:hasVertex [ city:x 19211 ;
  	city:y 19441 ;
  	city:z 0 ],

• Ontology terms are defined with relative URL in the context, resulting in local file: URLs in turtle:

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 34 in c46b466

  [ a <file:///home/alx5000/work/Proyectos/ogc/chek-profiles/Building> ;

• boundaries have a similar structure to vertices (list of numeric triples), but city:hasVertex vs city:boundaries have very different structure:
  

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 44 in c46b466

  city:hasVertex [ city:x 19211 ;

  vs
  

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 32 in c46b466

  city:boundaries ( ( ( 0 1 2 ) ) ( ( 3 4 5 ) ) ( ( 4 6 5 ) ) ( ( 2 7 6 ) ) ( ( 5 8 9 ) ) ( ( 0 2 4 ) ) ( ( 4 2 6 ) ) ( ( 5 6 8 ) ) ( ( 8 10 9 ) ) ( ( 11 12 13 ) ) ( ( 11 9 12 ) ) ( ( 12 10 14 ) ) ( ( 9 10 12 ) ) ( ( 15 5 11 ) ) ( ( 5 9 11 ) ) ( ( 16 3 17 ) ) ( ( 17 5 15 ) ) ( ( 3 5 17 ) ) ( ( 18 17 15 ) ) ( ( 16 19 20 ) ) ( ( 20 19 21 ) ) ( ( 21 19 7 ) ) ( ( 3 20 4 ) ) ( ( 21 7 2 ) ) ( ( 16 20 3 ) ) ( ( 22 2 1 ) ) ( ( 22 21 2 ) ) ( ( 23 1 0 ) ) ( ( 23 22 1 ) ) ( ( 23 4 20 ) ) ( ( 23 0 4 ) ) ( ( 19 24 6 ) ) ( ( 19 6 7 ) ) ( ( 24 25 8 ) ) ( ( 24 8 6 ) ) ( ( 25 10 8 ) ) ( ( 25 14 10 ) ) ( ( 26 27 28 ) ) ( ( 29 26 28 ) ) ( ( 30 26 29 ) ) ( ( 30 31 26 ) ) ( ( 32 13 12 ) ) ( ( 32 12 33 ) ) ( ( 34 32 33 ) ) ( ( 34 33 35 ) ) ( ( 36 37 38 ) ) ( ( 37 39 38 ) ) ( ( 40 41 42 ) ) ( ( 40 42 43 ) ) ( ( 44 40 43 ) ) ( ( 45 40 44 ) ) ( ( 45 44 46 ) ) ( ( 44 47 46 ) ) ( ( 36 46 47 ) ) ( ( 36 47 37 ) ) ( ( 18 35 17 ) ) ( ( 18 34 35 ) ) ( ( 48 49 50 ) ) ( ( 48 50 51 ) ) ( ( 41 51 42 ) ) ( ( 41 48 51 ) ) ( ( 52 27 53 ) ) ( ( 52 28 27 ) ) ( ( 54 31 30 ) ) ( ( 54 55 31 ) ) ( ( 56 52 53 ) ) ( ( 55 56 53 ) ) ( ( 54 56 55 ) ) ( ( 38 39 49 ) ) ( ( 39 50 49 ) ) ( ( 20 21 22 ) ) ( ( 23 20 22 ) ) ( ( 52 29 28 ) ) ( ( 56 29 52 ) ) ( ( 54 29 56 ) ) ( ( 54 30 29 ) ) ( ( 15 11 32 ) ) ( ( 18 15 34 ) ) ( ( 34 15 32 ) ) ( ( 32 11 13 ) ) ( ( 38 49 46 ) ) ( ( 45 46 41 ) ) ( ( 36 38 46 ) ) ( ( 45 41 40 ) ) ( ( 46 49 41 ) ) ( ( 41 49 48 ) ) ( ( 50 12 14 ) ) ( ( 39 12 50 ) ) ( ( 19 27 24 ) ) ( ( 53 27 19 ) ) ( ( 16 35 31 ) ) ( ( 31 37 44 ) ) ( ( 16 31 55 ) ) ( ( 27 43 51 ) ) ( ( 27 51 24 ) ) ( ( 35 37 31 ) ) ( ( 26 43 27 ) ) ( ( 31 44 26 ) ) ( ( 16 53 19 ) ) ( ( 26 44 43 ) ) ( ( 37 47 44 ) ) ( ( 16 55 53 ) ) ( ( 43 42 51 ) ) ( ( 50 14 25 ) ) ( ( 33 12 39 ) ) ( ( 35 33 37 ) ) ( ( 24 51 25 ) ) ( ( 16 17 35 ) ) ( ( 51 50 25 ) ) ( ( 37 33 39 ) ) ) ;

• city:hasVertex vs city:boundaries don't use a consistent naming convention (I prefer just vertex, boundary)
• city:lod "2" may be better rendered as a number (2 or even 2.0) so one can compare LODs numerically
  

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 33 in c46b466

  city:lod "2" ] ],

• city:hasTransform, city:translate are defined as xsd:float or double, leading to inexact numeric representation and scientific notation. Maybe better define as xsd:decimal?
  

  chek-profiles/cityjson/twobuildings.city.ttl

  Line 41 in c46b466

  city:translate [ city:x 3.005782e+05 ;

• (cosmetic) Nested blank nodes are not formatted well: city:x doesn't start in the same position as city:y, city:z:
  

  chek-profiles/cityjson/twobuildings.city.ttl

  Lines 24 to 29 in c46b466

  	city:geographicalExtent [ city:max [ city:x 3.006181e+05 ;
  	city:y 5.041289e+06 ;
  	city:z 2.945e+01 ] ;
  	city:min [ city:x 3.005782e+05 ;
  	city:y 5.041258e+06 ;
  	city:z 1.3688e+01 ] ] ;

• an important root object "Building_1" is missing from the turtle
  

  chek-profiles/cityjson/twobuildings.city.json

  Line 15 in c46b466

  "Building_1": {

@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 @avillar, and @pzaborowski @FrancescaNoardo, cc @nataschake
I'm looking at an example and trying to figure out how to decode CodeList values

https://github.com/opengeospatial/CityGML3.0-GML-Encoding/blob/main/resources/examples/Building/Building_CityGML3.0_LOD2_with_several_attributes.gml#L269 has this:

      <bldg:function>31001_9998</bldg:function>
      <bldg:roofType>3100</bldg:roofType>

• GML Conceptual Model https://docs.ogc.org/is/20-010/20-010.html#RoofTypeValue-section just says there is a codelist RoofTypeValue
• GML Encoding Standard https://docs.ogc.org/is/21-006r2/21-006r2.html has 25 occurences of "rooftype", including
  1. <bldg:roofType>3100</bldg:roofType>, <bldg:roofType>1030</bldg:roofType>
  2. <bldg:roofType>Flat</bldg:roofType>, <bldg:roofType>Saddle</bldg:roofType>: I think that it's inconsistent to use both codes and English words in the same element!
  3. https://docs.ogc.org/is/21-006r2/21-006r2.html#_gml gives example of defining 1000->flat roof, 3100->saddle roof in XML
     1. And refers to https://www.ogc.org/citygml/3.0/codelists/gml/rooftypes, which is Page not found
  4. https://docs.ogc.org/is/21-006r2/21-006r2.html#_comma_separated_values_csv_structure gives a simple understandable CSV, but only as an example

Does that mean there's no registry of the 130 or so GML codelists, and so each CityGML file uses codes that are not standardized anywhere?