You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a few problems trying to attach a Geopose to a GeoJSON feature either directly as a property, or using an Observation to reference a feature...
in that the geometry of the object should be able to serve as a position, on the principle that duplicating coordinates is a "Bad Thing" in general.
my actual use case is using a geopose as the "result" of an "Observation" from a feature with a known point. In this case the set of points form a geometric network described using topology, where other observations and calculations are used to determine position of individual vertices using the geoPose angles and a distance measurement, and one or more reference points. (e.g. least squares adjustment on a survey traverse")
IMHO "position" should be optional in the schema to support this conceptually.
Secondly, the lat/lon/h pattern for coordinates differs from the GeoJSON form adopted for OGC API features, and I wouldnt want two different syntaxes co-existing (not going to argue which is superior here - they are other options as well no doubt). Solved by making position optional.
Thirdly, geopose can conceptually be used in derivative 2D context - so making h required seems over strict. In the same vein pitch and roll coudl be optional allowing a degenerate simple bearing option of a geopose.
Would still like to be able to use geopose - because it means we can use the same schema and conceptual model to move from 2D to 3D applications without change - just changing some profile restrictions to make h and pitch required...
Could my hacked, lenient YPR schema could be registered as a implementation of GeoPose ?
The text was updated successfully, but these errors were encountered:
There are a few problems trying to attach a Geopose to a GeoJSON feature either directly as a property, or using an Observation to reference a feature...
my actual use case is using a geopose as the "result" of an "Observation" from a feature with a known point. In this case the set of points form a geometric network described using topology, where other observations and calculations are used to determine position of individual vertices using the geoPose angles and a distance measurement, and one or more reference points. (e.g. least squares adjustment on a survey traverse")
IMHO "position" should be optional in the schema to support this conceptually.
Secondly, the lat/lon/h pattern for coordinates differs from the GeoJSON form adopted for OGC API features, and I wouldnt want two different syntaxes co-existing (not going to argue which is superior here - they are other options as well no doubt). Solved by making position optional.
Thirdly, geopose can conceptually be used in derivative 2D context - so making h required seems over strict. In the same vein pitch and roll coudl be optional allowing a degenerate simple bearing option of a geopose.
Would still like to be able to use geopose - because it means we can use the same schema and conceptual model to move from 2D to 3D applications without change - just changing some profile restrictions to make h and pitch required...
Could my hacked, lenient YPR schema could be registered as a implementation of GeoPose ?
The text was updated successfully, but these errors were encountered: