This issue is the body of an e-mail sent by Jerome St-Louis on Sept 9, 2021
First I think we need to make the distinction between the more abstract concept of a GeoPose, and then the particular GeoPose JSON encoding.
I think the former is more relevant to OGC API - Features than the latter, as GeoJSON used in Features already prescribes a mechanism to describe positions through the geometry property of its features.
One use we already make of a GeoPose (at least at the conceptual level) is instantiation of referenced 3D models such as buildings or trees in 3D datasets.
Each building and tree has a position, and in some cases an orientation as well.
Orientation is more useful for geotypical models like trees where a forest can be built out of just a few models but tweaking orientation and/or scaling for things to look more natural.
Since the GeoJSON geometry property already provides the latitude, longitude and height, we only need to add the orientation (as 'yaw', or optionally as yaw/pitch/roll if the additional degrees of freedom are desired) as GeoJSON properties for the features.
An implementation of this in our OGC API - Features implementation is found here:
The position is in the geometry, and the "model::orientation" stores a Yaw,Pitch,Roll orientation.
The corresponding original orientation property from CDB 1.x is also included (AO1).
Notice that the tree feature can be a MultiPoint instantiating multiple trees using the same models,but only for instances having the exact same orientation,because the orientation is stored in a property and properties are per-feature rather than per point,
The 3D models being "GeoPosed" are referenced by the "model::id" property for which e.g. a glTF model can be downloaded using that ID:
and will likely be one mechanism to distribute 3D content in GeoVolumes extending the Tiles API to 3D following that approach.
I believe all of this is much in line with GeoPose, in that it includes both a position and orientation, and the 3D orientation is relative to the plane tangent to the surface of the Earth at that position.
I'm not 100% sure whether the signs of the YPR angles follow the GeoPose specification, we could verify.
The yaw angle is usually positive clockwise from the North, not sure about pitch & roll.
Additional background and context would also be found in the following documents:
cperey
commented
3 years ago
This issue is the body of an e-mail sent by Jerome St-Louis on Sept 9, 2021
First I think we need to make the distinction between the more abstract concept of a GeoPose, and then the particular GeoPose JSON encoding. I think the former is more relevant to OGC API - Features than the latter, as GeoJSON used in Features already prescribes a mechanism to describe positions through the geometry property of its features.
One use we already make of a GeoPose (at least at the conceptual level) is instantiation of referenced 3D models such as buildings or trees in 3D datasets. Each building and tree has a position, and in some cases an orientation as well. Orientation is more useful for geotypical models like trees where a forest can be built out of just a few models but tweaking orientation and/or scaling for things to look more natural.
Since the GeoJSON geometry property already provides the latitude, longitude and height, we only need to add the orientation (as 'yaw', or optionally as yaw/pitch/roll if the additional degrees of freedom are desired) as GeoJSON properties for the features.
An implementation of this in our OGC API - Features implementation is found here:
https://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Buildings https://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Trees
e.g.
https://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Trees/items/1.json https://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Buildings/items/1.json
The position is in the geometry, and the "model::orientation" stores a Yaw,Pitch,Roll orientation. The corresponding original orientation property from CDB 1.x is also included (AO1).
Notice that the tree feature can be a MultiPoint instantiating multiple trees using the same models,but only for instances having the exact same orientation,because the orientation is stored in a property and properties are per-feature rather than per point,
The 3D models being "GeoPosed" are referenced by the "model::id" property for which e.g. a glTF model can be downloaded using that ID:
This concept of positioning & orienting 3D models is also used:
I believe all of this is much in line with GeoPose, in that it includes both a position and orientation, and the 3D orientation is relative to the plane tangent to the surface of the Earth at that position. I'm not 100% sure whether the signs of the YPR angles follow the GeoPose specification, we could verify. The yaw angle is usually positive clockwise from the North, not sure about pitch & roll.
Additional background and context would also be found in the following documents:
OGC Testbed-14: CityGML and AR Engineering Report ( https://docs.ogc.org/per/18-025.html )
Interoperable Simulation and Gaming Sprint Engineering Report ( http://docs.ogc.org/per/20-087.html )
ISG Year 2 ER ( https://github.com/opengeospatial/OGC-ISG-Sprint-Sep-2020/tree/master/Sprint%20Report -- not yet published )
GeoVolumes charter ( https://portal.ogc.org/files/97171 )