Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Standardization of textures for geometries #438

Open
wouterbeek opened this issue Sep 8, 2023 · 4 comments · May be fixed by #443
Open

Standardization of textures for geometries #438

wouterbeek opened this issue Sep 8, 2023 · 4 comments · May be fixed by #443
Milestone
GeoSPARQL 1.3

Comments

@wouterbeek
Copy link

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
Copy link
Collaborator

situx commented Sep 8, 2023

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.

@jabhay jabhay added this to the GeoSPARQL 1.3 milestone Sep 20, 2023
@HubertMara
Copy link

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
Copy link
Collaborator

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

@situx situx linked a pull request Oct 6, 2023 that will close this issue
Draft
@mathib
Copy link
Contributor

mathib commented Dec 22, 2023

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).

@wouterbeek wouterbeek mentioned this issue Nov 5, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
GeoSPARQL 1.3
Development

Successfully merging a pull request may close this issue.

Draft for inclusion of surface textures and materials opengeospatial/ogc-geosparql
6 participants
@wouterbeek @situx @lvdbrink @jabhay @mathib @HubertMara