KhronosGroup / glTF

glTF – Runtime 3D Asset Delivery
Other
7.07k stars 1.13k forks source link

Geospatial Profile #2092

Open DRx3D opened 2 years ago

DRx3D commented 2 years ago

Preliminary Draft

Introduction

The Geospatial Investigatory Subcommittee is publishing this issue to start the discussion of a Geospatial Profile. The GIS developed this preliminary draft of a profile to discuss within the glTF Community.

This discussions uses the definition of a glTF Profile to be a collection of extensions that are necessary to meet most of the requirements for work with 3D models in that field. At this time of the discussion, it is not necessary for all of the extensions to be ratified or even developed. It does identify the features and capabilities that are necessary for those extensions. There is nothing in the existence of the profile that requires a change to Core glTF V2.0.x

Geospatial applications are the collection of data, models, and software that allow the visualization and analysis of information that is tied to a location. It is frequently used to refer to Earth-based location, but that is not an explicit requirement.

Capabilities

The following high-level capabilities are required to support geospatial applications. The existing extensions that support these capabilities are listed below.

Point Cloud

Point clouds are incompletely supported by glTF. The existing extensions are necessary. Note that not all of the extensions are ratified (KHR_*). We anticipate the capabilities defined in the unratified extensions to be incorporated into ratified ones at a future point in time.

Other profile capabilities may also provide support for point clouds. This list is not meant to exclude them. We found it very encouraging that JPEG Pleno (ISO SC 29) has done a lot of initial work to develop a standardization for point cloud data files, including developing an extensive Use Case document.

Metadata

This capabilities includes providing support for metadata throughout the glTF file at the file, scene, node, and texel levels. Much of the node and above support is provided through an ratified extension. It is still necessary to develop and standardize the vocabulary used for Geospatial. This may best be done in conjunction with other organizations, especially Open Geospatial Consortium.

Layers

Layers is the mechanism to group various objects for ease of analysis and visualization. There are no specific extensions. Esri has a document that describes I3S & Profile.

Compression

Point cloud and other geospatial data can get very huge (>> 1GB). Various compression and streaming mechanisms are necessary to effectively deal with that much data. Meshopt was listed above.

GeoPose

GeoPose is an OGC developed standard for defining the location, orientation, and time history of any object.

LOD/Embedded spatial data structure

This capability category is currently insufficiently implemented. There is one LOD extension that does not fully meet the needs of Geospatial applications (source is currently under review and unpublished). The required capability needs to support streaming levels and provide better controls over the data that is used.

Rendering

This capability was not fully discussed and is subject to substantial change. It include extensions necessary to render the same object many (hundreds+) times without significant performance degradation. There is an initial version of this capability in the extension

An unexplored area is the handling of real-world marker lights. These are lights that are found associated with airports such as taxiways, runways, approach. By regulation, these lights have very specific characteristics in terms of color, brightness, etc. that are critically important to flight systems such as simulators.

Conclusion

This is just an preliminary draft of the needs for Geospatial applications. All additional ideas are welcome either by adding comments to this issue or raising them with the 3D Formats Working Group or Geospatial Investigatory Subcommittee. It is anticipated that the specific details discussed here will change over time. A number of extensions are needed to complete the profile and work on these concept extensions is highly encouraged. If you would like to participate, please post a comment.

wallabyway commented 2 years ago

Some 'Metadata' links are broken... ie.

glTF: EXT_mesh_features (draft) 3D Tiles: 3DTILES_metadata 3D Tiles: 3DTILES_multiple_contents

donmccurdy commented 2 years ago

The 3D tiles drafts were merged to the 'main' branch of the repository, and can be found here:

https://github.com/CesiumGS/3d-tiles/tree/main/next

pjcozzi commented 2 years ago

@DrX3D thanks for starting this topic.

Adding links to analogy topics in the 3D Tiles repo:

We hope the first one is a near-term item; we the other two will benefit from more discussion on what to do right away and what to roadmap for the longer term.

jsorel commented 2 years ago

to be taken in consideration : https://github.com/KhronosGroup/glTF/issues/2106

cnreediii commented 2 years ago

Not to be difficult, but given that GIS is an abbreviation for Geographic Information Systems that has been used since the mid 1960s, you might want to consider some other abbreviation (or Group name) that will not confuse GIS folks like me :-)

andreasplesch commented 2 years ago

Please keep subsurface use cases in mind, eg. wells, mines or earthquakes, for engineering or scientific purposes.

GeoPose seems general enough but does not include those among the use cases in the specification draft. There also has been extensive discussion about the vertical dimension. I believe the vertical coordinate is labeled h and refers to height in meters above the WGS84 ellipsoid. It can be negative but that is not explicitly mentioned. There is a comment that other vertical datum choices are often used in industries.

Tamrat-B commented 2 years ago

updated I3S link above to reference latest OGC version (1.2).