3D Primitives Vocabulary and Alignments to IFC, CityRDF and X3D

[situx]

This pull request starts to consolidate the following things:

1. A vocabulary simply called "Simple Features 3D" for 3D primitives common in other 3D vocabularies
   • Curve Types as extensions to the Simple Features Vocabulary (e.g., BSplineCurve)
   • Surface Types as defined from different curves (e.g. BSplineSurface)
   • 3D Primitives in use in other 3D formats: e.g., Cone, Cylinder, etc.
   • Literal types to encode common 3D types Triply Use Case 1: Support for GLTF and other 3D formats #583
   • Material and Texture classes, which may or may not be replaced by CityRDF Appearance Module see Triply Use Case 2: Support for textures #584
2. Alignments to:
   • IFC also to collect concepts for the IFC Profile Triply Use Case 8: GeoSPARQL profile for IFC #590
   • X3D Web3D and X3D Ontology #571

Missing points:

• Are all geometry types included in this vocabulary?
• Did we cover all relevant literal types?
• Is the naming appropriate?
• Any additions to the alignments?

[paulc-dstl]

The set of 3D shapes is looking good. But just to note, some 3D shapes (geometries) can be either solid or not. A cube for example may be a mesh rather than a solid object (ie the cube comprises six faces but is hollow). This is analogous to a polyline having coincident start and end points but not being closed. So I think we need some facets here to allow for polyhierarchy, bearing in mind also that some 3D shapes are neither meshes (ie have no faces) nor are solid, for example a 3D polyline or a pointcloud.

[situx]

Thanks @paulc-dstl
Then it would be better to classify them as 3DGeometries and use the property geo:isClosed and geof:isClosed to describe them?

[situx]

Meeting 5th February:

• @ar-chad investigates whether it is possible to generalize the Appearance module of CityRDF for the use within GeoSPARQL and how to align it
• @jabhay investigates whether it is possible to extend the Simple Feature Access Vocabulary with 3D types as proposed in this pull request or whether a separate vocabulary namespace is needed
• @nicholascar to follow up with Rob Atkinson on the review of the 3D primitives.
• @situx to separate the appearance module parts from the simple features 3D class hierarchy

[ar-chad]

Meeting 5th February:

• @ar-chad investigates whether it is possible to generalize the Appearance module of CityRDF for the use within GeoSPARQL and how to align it

I have started investigation on this ogcincubator/cityrdf#15

[nataschake]

Hi!
Here is a separated module for Appearance ontology, taken from CityRDF and defining all necessary classes within itself. CityRDF itself (mainly Core and Appearance) still needs to be carefully tested, but you can evaluate the idea.

[ar-chad]

@nataschake GeoSPARQL is only one of the ontologies which would use this appearance ontology, CityRDF another one. There may be even more in the future. We discussed making it independent of other ontologies so it could be imported by them or aligned with in another way.

[situx]

Since the appearance module has now been excluded from this pull request I will try to finalize the 3D primitive vocabulary and then set this pull request as ready to review