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.

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

Triply Use Case 2: Support for textures #584

Open
wouterbeek opened this issue Nov 5, 2024 · 1 comment
Open

Triply Use Case 2: Support for textures #584

wouterbeek opened this issue Nov 5, 2024 · 1 comment

Comments

@wouterbeek
Copy link

Triply Use Case 2: Support for textures

Description

In GeoSPARQL, I can represent and load 3D geometries in GML or WKT. But these geometries are boxes without texture. When I obtain textures, I cannot store them in relation to their corresponding 3D geometries with a standardized relationship. Originally reported by me in #438, including many insightful comments by others.

Actor

  • Data Expert

Preconditions

  • One or more 3D objects in a GeoSPARQL dataset.
  • Textures that belong to these 3D objects, stored in separate files.
  • Information about how the textures apply to the objects, e.g. where the texture should start and end (otherwise the front door would appear on the back of a building).

Postconditions

  • The 3D objects in my GeoSPARQL dataset have textures. Geospatial and texture data is fully integrated.

Steps

  1. I have 3D GeoSPARQL objects in my triple store.
  2. I have textures for these objects in separate files.
  3. I can integrate the textures into my GeoSPARQL dataset. Either by linking to the files, or by integrating the file content into a (binary) literal.
  4. When I query my data, I can show the 3D objects on a map, together with their textures. The triple store knows how the textures should be applied to the 3D objects, as long as I have specified sufficient information for how this should be done.
@ar-chad
Copy link
Collaborator

ar-chad commented Nov 14, 2024

@wouterbeek you can describe your model in terms of CityGML standard and use Appearance module to include textures and texture coordinates, in particular https://docs.ogc.org/is/20-010/20-010.html#TexCoordList-section

There is ongoing work on CityRDF, which is going to turn this standard to an ontology https://github.com/ogcincubator/cityrdf

In short, CityGML adds additional semantics on top of GML. This allows you to specify if a particular geometry is a wall or a floor, etc. And the Appearance module, in particular, allows you to add texture information to such descriptions.

GeoSPARQL specifically can be used to query geometry layer (including texture coordinates) of such descriptions and SPARQL can be used for anything else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants