Standardization of textures for geometries

[wouterbeek]

Observation

An increasing number of linked data users are building 3D Digital Twins with GeoSPARQL. In a 3D Digital Twin, the textures that are displayed on top of the geometries are often important. There are linked data standards about storing images and there is GeoSPARQL for storing (3D) geometries. But there are enough challenges in combining the two that require further standardization.

Expected

Standardization of the way in which textures and geometries should be optimally combined. This may include how the texture is positioned on top of the geometry, and how the texture and geometry are related (e.g. geo:hasTexture).

Additional remarks

I am supplier of the TriplyDB linked data product. As a supplier, I receive the question above increasingly often, so I can detect the demand for standardization in this area. I am not a geo/3D expert, so I do not know how standardization of this issue should look like. (But if this would be standardized, then I would be able to act as one of the first implementors.)

[situx]

Hi @wouterbeek this seems like a good idea to me that would also fit the roadmap for the next revision of GeoSPARQL we are currently working on. As we are working on fully-featured 3D support for the next revision of GeoSPARQL, any proposals in that direction are welcome. Can you share examples of people who have made attempts in these directions that we could have a look at? Also, as anyone, you are very welcome to join our bi-weekly calls (as OGC member or not) to discuss the issue further. For the link, just write a mail to our mailing list which you can find in the README of this repository.

[HubertMara]

If there is a geo:hasTexture there also should be a geo:hasVertexColor as both coloring options are quite relevant. In the realms of 3D acquisition the texture maps are typically for Structure from Motion (SfM) models, while the color per vertex is used by Structured Light Scanning (SLS). There are cases where both of them are present. Another common field in 3D metrology is quality (per vertex). It is used for a number of things beside what's suggested by the name. E.g. in http://gigamesh.eu it is used to transfer scalar values for tasks like segmentation and machine learning in general.

[lvdbrink]

CityJSON could be a source of inspiration here: https://www.cityjson.org/specs/1.1.3/#appearance-object

[mathib]

I believe the original question is about adding textures (and colors through the remark) to geometry description formats such as WKT, GeoJSON, etc. which don't have a notion of textures or colors. Partially related to the subject are rendering materials, but these have much more to do with visual representation styles instead of actual "hard" data related to the geometry.

On the other hand, plenty of relevant existing 3D geometry formats (e.g. OBJ, glTF/GLB, IFC, etc.) have already a way to deal with textures, materials and colors, either embedded or through a referencing system to separate files/blobs.

Personally, I don't think the GeoSPARQL spec should demand to those existing formats with support for textures, materials and colors to leave all of that to GeoSPARQL. At the same time it would be super useful if spatial functions are allowed with such formats. Running a bit ahead, but it sounds to me that textures-colors-materials is rather a subject for a non-normative section inside GeoSPARQL and only applicable when the format has no support for it (else there would be a chance for duplication of data).