Terminology needed to express relations between geometry descriptions

[FransKnibbe]

Contributed by Anna Wagner and Mathias Bonduel for the white paper "Benefits of Representing Spatial Data using Semantic and Graph Technologies":

If multiple geometry descriptions can be attached to one object, or if objects are related to each other, it would be useful to also define relations between the geometry descriptions directly, that are of other nature than purely topological. We propose to extend the schema to also describe the following relations:

1. grouping of geometry descriptions, e.g. for use cases;
2. describing derivations of multiple geometry descriptions, i.e. to ease maintaining consistent data;
3. transforming geometry descriptions to avoid redundant geometry descriptions;
4. referencing parts of a large geometry description as geometry representation of a smaller object

These relations are currently implemented in the Ontology for Managing Geometry (OMG, https://w3id.org/omg). The individual use cases and current implementations are presented below.

1. Grouping: In the AEC industry, geometry can be necessary in multiple use cases, e.g. heating calculation software needs BREP geometry of internal and external space volumes and their connections or an architect wants to communicate the geometry of a specific version of his design to a client. If the according geometry representations (BREP, mesh, CSG, etc.) of all relevant geometry descriptions could be extracted by a simple query that extracts the relevant group, these processes could be automated more swiftly. In OMG, this is currently implemented via a geometry context. Several omg:Geometry or omg:GeometryState (version) instances can be linked to an omg:GeometryContext instance via the omg:hasGeometryContext property.
2. Deriving: Derivation of geometry descriptions occur in two cases: either, a geometry is converted from one schema into another, or a geometry is processed for a certain use case. The first case is usually conducted due to software application interoperability, where one application outputs one schema and another application requires a different one. The second case has more diverse reasons, for example, a BREP/CSG/NURBS geometry could be modeled based on a point cloud or a mesh coming from a survey, a 3D BREP model is created from 2D CAD drawings (elevations, plans, sections), or certain parts of the geometry are filtered for simulations, e.g. only outside faces for raytracing simulations. This relation is currently implemented in OMG on both geometry description, as well as geometry version level via the omg:isDerivedFromGeometry and omg:isDerivedFromGeometryState properties, respectively. These properties can create links between two instances of omg:Geometry or omg:GeometryState to indicate the derivation or -- if version control is used -- potential derivations (e.g. a geometry in OBJ serialisation can be derived from geometries in STEP or DWG serialisations)
3. Transforming: A building model can contain a manyfold of identical objects, such as doors, that share the same geometrical form, but have a different location. The object’s geometry is supplied by the manufacturer, but the designer has to decide the location of each door in the building. If the geometry has to be copied for every instance of the object, this can immensely inflate the total size of geometry descriptions and also bears the danger of data inconsistency. For example, if the manufacturer changes a minor detail of the description, each copy needs to be adapted or replaced. Instead, the geometry instances could contain a transformation matrix and a link to the original geometry description, effectively reducing file size and risk for inconsistency. Currently, this relation is implemented in OMG on the omg:Geometry node level. The omg:transformsGeometry property can link between two instances of omg:Geometry, where the instantiated geometry (subject) has no individual geometry description (thus no omg:hasSimpleGeometryDescription / omg:hasComplexGeometryDescription), but only a transformation definition connected (matrix, vector, etc) while the origin geometry (object) contains the complete geometry description in its own custom coordinate system.
4. Referencing: During a modeling phase, it is easier to store the geometry in a single file using the native geometry schema of the modeling application. At the same time, it is relevant to know which parts of the larger geometry description correspond to an individual building object. Hence, subparts of the building model should be connected to individual building elements, if the applied geometry format allows this, e.g. by providing identifiers for parts of the geometry description. In OMG this relation is currently implemented via the omg:isPartOfGeometry property between two instances of omg:Geometry. The partial geometry (subject) is referenced using one or multiple omg:hasReferencedGeometryId properties (with subproperties per kind of identifier per geometry schema in File Ontology for Geometry formats (FOG, https://w3id.org/fog)) that can be applied to the main geometry (object) to extract the subgeometry by processing.

Also see the following publications for OMG and FOG:

• Wagner, A., Bonduel, M., Pauwels, P., & Uwe, R. (2019). Relating geometry descriptions to its derivatives on the web. In Proceedings of the European Conference on Computing in Construction (EC3 2019) (pp. 304–313). Chania, Greece. https://doi.org/10.35490/EC3.2019.146

• Bonduel, M., Wagner, A., Pauwels, P., Vergauwen, M., & Klein, R. (2019). Including widespread geometry formats in semantic graphs using RDF literals. In Proceedings of the European Conference on Computing in Construction (EC3 2019) (pp. 341–350). Chania, Greece. https://doi.org/10.35490/EC3.2019.166

[mathib]

(original contribution raised by @AnnaWagner and I)

[mathib]

added to OGC standards tracker: http://ogc.standardstracker.org/show_request.cgi?id=639

[jabhay]

Created MoSCoW poll