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 11: Represent the same information at different LOD levels #593

Open
wouterbeek opened this issue Nov 5, 2024 · 2 comments

Comments

@wouterbeek
Copy link

Triply Use Case 11: Represent the same information at different LOD levels

Note: In this issue, LOD standards for "Levels of Detail" and not for "Linked Open Data".

Description

When I load one building, I want to see all the details. But when I load a while city, seeing all the details is not useful and will crash my web browser.

Thanks for marking up by 3D GeoSPARQL data into different LODs, I can offer one dataset that allows 3D data to be viewed at the level of a country, province, city, neighborhood, street, building, or room. At each zoom level, a corresponding LOD may be used, so that applications can guarantee a consistent experience of performance when moving between these different levels.

Actor

  • Agencies that publish large quantities of 3D data (city- or country-level agencies).
  • Users of such city- or country-level datasets.

Preconditions

  • Large quantities of 3D GeoSPARQL data.
  • Web browser that do not have unlimited hardware resources.

Postconditions

  • A fluent performance experience when navigating large quantities of 3D GeoSPARQL data, by zooming in and out.

Steps

  1. As a nation-wide publication office, I have high-LOD 3D geodata about many building in the country in which I operate.
  2. In a batch job, I generate lower resolution / lower LOD versions of my geodata. GeoSPARQL 3D allows me to store these lower LOD levels, with standardized properties.
  3. My users can set the LOD per zoom level, so that zooming works in a performant way.
@FransKnibbe
Copy link
Collaborator

FransKnibbe commented Nov 7, 2024

GeoSPARQL already has the ability to indicate the spatial resolution of a geometry (geo:hasSpatialResolution and geo:hasMetricSpatialResolution), and therefore the ability to represent a Feature with multiple geometries that each have a different optimal visualisation resolution, but the ability to use a standard data structure to encode ranges of resolution could be useful. Such a thing could be used to encode the LODs of CityGML, but it is imaginable that similar standard LODs are nice to have for geometric data at other scales, e.g. microscopic or astronomic scales.

Also. an indication of LODs is useful to have at the dataset level (dataset metadata). A property like dcat:spatialResolutionInMeters can only describe one LOD for a dataset.

@ar-chad
Copy link
Collaborator

ar-chad commented Nov 14, 2024

@wouterbeek, @FransKnibbe there is already ongoing work on CityRDF ontology https://github.com/ogcincubator/cityrdf in the OGC incubator, which is a semantic web equivalent to CItyGML. CityGML already includes LOD concept and relevant predicates https://docs.ogc.org/is/20-010/20-010.html#toc24

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

3 participants