3D extensions #29
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,7 +9,7 @@ It helps to identify some of the barriers to use, and to outline requirements th | |
|
|
||
| ===== GitHub Issue URI | ||
|
|
||
| - https://github.com/opengeospatial/ogc-geosparql/issues/583 | ||
|
|
||
| ===== Category | ||
|
|
||
|
|
@@ -19,7 +19,7 @@ Semantic improvement | |
|
|
||
| GeoSPARQL should include ways to represent 3D data in a knowledge graph. | ||
|
|
||
| 3D data should be included in common 3D formats, and it should be possible to ingest 3D data in a form of a text literal representation or a file including multiple literals. | ||
|
|
||
| Some common formats which could be considered for inclusion are: | ||
|
|
||
|
|
@@ -32,7 +32,15 @@ Some common formats which could be considered for inclusion are: | |
|
|
||
| ===== GitHub Issue URI | ||
|
|
||
| - https://github.com/opengeospatial/ogc-geosparql/issues/416 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/578 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/577 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/566 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/567 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/600 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/601 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/606 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/581 | ||
|
|
||
| ===== Category | ||
|
|
||
|
|
@@ -41,13 +49,15 @@ Semantic improvement | |
| ===== Description | ||
|
|
||
| GeoSPARQL should include ways to represent relations between 3D geometries and relations between 3D geometries and geometries of lower dimensions. | ||
| It should be possible to express the relations as property relations. It should be also possible to query concerning the relations using SPARQL extension functions. Closest point and closest coordinate functions are examples of functions allowing to measure distances between 3D geometries on different planes. Shortest and longest line functions return lines corresponding to appropriate distances. Access to such functions will allow urban planners getting insight on the usage of public space to place objects at the right locations. Functions to detect and operate on shared boundaries between 3D geometries should be also included. | ||
|
|
||
| ==== Extension {counter:ext}: Appearance of 3D geometries | ||
|
|
||
| ===== GitHub Issue URI | ||
|
|
||
| - https://github.com/opengeospatial/ogc-geosparql/issues/592 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/584 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/593 | ||
|
|
||
| ===== Category | ||
|
|
||
|
|
@@ -62,11 +72,15 @@ Materials include: | |
| - Colors of surfaces with light diffusion parameters | ||
| - Images as textures, which are associated with surfaces of the 3D object | ||
|
|
||
| GeoSPARQL should also support queries of different levels of detail on 3D geometry sets. One dataset should allow 3D data to be viewed at the level of a country, province, city, neighborhood, street, building, or room, etc. | ||
|
|
||
| ==== Extension {counter:ext}: Multi-component 3D geometries | ||
|
|
||
| ===== GitHub Issue URI | ||
|
|
||
| - https://github.com/opengeospatial/ogc-geosparql/issues/591 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/597 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/595 | ||
|
|
||
| ===== Category | ||
|
|
||
|
|
@@ -75,13 +89,18 @@ Semantic improvement | |
| ===== Description | ||
|
|
||
| GeoSPARQL should include ways to define multi-component 3D geometries, whereas each component expresses its own semantics. | ||
| For example, parts of a building could have different semantics according to the function of the building components and would be classified as such in an RDF graph. GeoSPARQL should also allow to query for subsets of multi-component geometries as well as aggregation of disjoint geometries. | ||
|
|
||
| ==== Extension {counter:ext}: Positioning of 3D geometries | ||
|
|
||
| ===== GitHub Issue URI | ||
|
|
||
| - https://github.com/opengeospatial/ogc-geosparql/issues/591 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/559 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/560 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/576 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/604 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/587 | ||
|
|
||
| ===== Category | ||
|
|
||
|
|
@@ -91,7 +110,7 @@ Semantic improvement | |
|
|
||
| GeoSPARQL should include ways to position 3D geometries in a 3D space. | ||
| Commonly 3D geometries are rotated, translated and scaled using commonly defined operators in computer graphics. | ||
| Similar operations are needed for the relative positioning of 3D objects in GeoSPARQL, as properties and potentially as functions. One type of functions, particularly useful in urban planning scenarios, is to change Z coordinates of a 3D geometry. Such operations allow for adjustments to models produced without accounting for elevation as well as better reuse of 3D models where only elevations are different. Flip X, Y coordinates function allows to reposition geometries in another dimension. More general transformations by matrix are also introduced. | ||
|
|
||
| ==== Extension {counter:ext}: Alignments of GeoSPARQL 3D | ||
|
|
||
|
|
@@ -100,21 +119,28 @@ Similar operations are needed for the relative positioning of 3D objects in GeoS | |
| - https://github.com/opengeospatial/ogc-geosparql/issues/590 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/574 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/571 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/598 | ||
|
|
||
| ===== Category | ||
|
|
||
| Semantic improvement | ||
|
|
||
| ===== Description | ||
|
|
||
| GeoSPARQL 3D should be aligned with other vocabularies and standards which currently provide 3D support in different knowledge domains. | ||
| Especially alignments with https://technical.buildingsmart.org/standards/ifc/ifc-formats/ifcowl/[ifcOWL] and the https://www.web3d.org/x3d/content/semantics/semantics.html[X3D vocabulary] would position the GeoSPARQL vocabulary as a link between these standards. At the same time GeoSPARQL should not include advanced procedural geometric concepts from IFC. | ||
|
Collaborator
There was a problem hiding this comment. "At the same time GeoSPARQL should not include advanced procedural geometric concepts from IFC." This statement should be explained: what are those advanced procedural geometric concept, and why shouldn't they be included?
Collaborator
There was a problem hiding this comment. I am also not sure which concepts are being referred to. @FransKnibbe would you be okay if we deleted this sentence in the absence of @ar-chad contributions? |
||
|
|
||
| ==== Extension {counter:ext}: Alignments of Engineering CRS to Geospatial CRS | ||
|
|
||
| ===== GitHub Issue URI | ||
|
|
||
| - https://github.com/opengeospatial/ogc-geosparql/issues/586 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/599 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/585 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/587 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/588 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/589 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/594 | ||
|
|
||
| ===== Category | ||
|
|
||
|
|
@@ -123,22 +149,7 @@ Semantic improvement | |
| ===== Description | ||
|
|
||
| GeoSPARQL 3D should provide the opportunity to align a local coordinate system in which most 3D geometries are defined with a coordinate reference. | ||
| While this work might only be partially done within the scope of GeoSPARQL itself, GeoSPARQL should be aligned with the emerging https://github.com/opengeospatial/ontology-crs[Ontology CRS] developments of OGC and provide necessary functions or properties to create the link. There should be also validation function allowing to assess if a particular CRS could be applied to 3D geometries and functions for storing information about coordinate resolution per axis. | ||
|
situx marked this conversation as resolved.
Outdated
|
||
|
|
||
|
|
||
| ==== Extension {counter:ext}: Geometry Attributes | ||
|
|
@@ -157,7 +168,7 @@ Semantic improvement | |
|
|
||
| ===== Description | ||
|
|
||
| GeoSPARQL 3D should provide functions and properties that describe essential properties of a 3D Geometry such as its minimum and maximum height, width and depth and its compactness ratio. | ||
|
|
||
| ==== Extension {counter:ext}: Non-topological Query Functions - 3D Extension | ||
|
|
||
|
|
@@ -176,3 +187,52 @@ GeoSPARQL 3D should provide the opportunity to execute non-topological query fun | |
| - geometry extrusion to the specified line segment | ||
| - geometry extrusion to the specified height | ||
| - spatiotemporal geometry extrusion to the specified line segment with specific start and end time | ||
|
|
||
| ==== Extension {counter:ext}: Ratios Between Geometry Properties | ||
|
|
||
| ===== GitHub Issue URI | ||
|
|
||
| - https://github.com/opengeospatial/ogc-geosparql/issues/551 | ||
|
|
||
| ===== Category | ||
|
|
||
| Semantic improvement | ||
|
|
||
| ===== Description | ||
|
|
||
| GeoSPARQL 3D should provide means to assess ratios between geometry properties. Proposed function comparing percentage area ratio will be useful in AECO industry use cases such as measuring ratio of total floor area of a building to land parcel area for compliance checking. The function allows to compare ratios of 2D area with surface area of 3D geometries apart from measuring area ratios for geometries of the same dimensionality. | ||
|
situx marked this conversation as resolved.
|
||
|
|
||
| ==== Extension {counter:ext}: 3D Geometry Analysis | ||
|
|
||
| ===== GitHub Issue URI | ||
|
|
||
| - https://github.com/opengeospatial/ogc-geosparql/issues/552 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/579 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/580 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/596 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/582 | ||
|
|
||
| ===== Category | ||
|
|
||
| Semantic improvement | ||
|
|
||
| ===== Description | ||
|
|
||
| GeoSPARQL 3D should provide functions useful for 3D geometry analysis. An example of such function is gross footprint area of 3D geometry sliced at a certain level. For instance, urban planners will be able to use this function to estimate the gross floor area of the building by slicing at the specified floor heights whenever they work with 3D models have only the building exterior, plus a specification of floor heights (but not the individual floors as distinct features). There should be also support for modeling and analysis of more complex geometry aggregates (e.g. volumetric survey plans and their intersecting parts). | ||
|
|
||
| ==== Extension {counter:ext}: Geometry Transformations | ||
|
|
||
| ===== GitHub Issue URI | ||
|
|
||
| - https://github.com/opengeospatial/ogc-geosparql/issues/561 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/602 | ||
| - https://github.com/opengeospatial/ogc-geosparql/issues/547 | ||
|
|
||
| ===== Category | ||
|
|
||
| Semantic improvement | ||
|
|
||
| ===== Description | ||
|
|
||
| GeoSPARQL 3D should provide functions useful for geometry transformations and complex 3D geometry representations. One such example is use of triangulated irregular networks (TIN) for digital elevation models (DEMs), digital surface models (DSMs) or digital terrain models (DTMs). Turning any geometry into TIN will allow for integrating it into such models. Translation by vector function allows for geometry alignments and adjustments while preserving relations between its points. | ||
|
|
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is already supported in GeoSPARQL 1.1.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GeoSPARQL 1.1 allows to state the spatial resolution as a property. In that way you could distinguish LOD, correct. Maybe @ar-chad means to distinguish LOD by other means, e.g. instances of "LOD" which might be "Room", "City" etc? That would make sense to me. In that regard, should we keep this sentence @FransKnibbe ?