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 ?
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 ?