Javier Jimenez Shaw via PROJ <[email protected]> writes: > Is there a way to add the geoid model in the short id of a CRS? There is a > way to put the epoch with an @. Maybe another way to set the geoid model? > > (dynamic) CRS with an epoch: EPSG:[email protected] > Compound CRS: EPSG:6516+5703 > > Many users want to set the geoid model used. Something like (but not > necessarily) > EPSG:6516+5703[GEOID12B]
This seems conceptually problematic. I don't think epoch and geoid model are at all the same kind of thing. I think this isn't related to compound CRS so much as the definition of a vertical CRS. 5703 is NAVD88. That is still, as far as I know, defined by passive controls. People obtain estimates of NAVD88 heights by using HAE (surely mostly in EPSG:6319) and then using a geoid model. Of course, all measurements are estimates and the traditional approach is leveling from passive controls, also an estimate. Presumably someone wanting to write EPSG:5703[GEOID12B] is saying that the heights were obtained via HAE and then transformed to NAV88. That's an estimate of HAE combined with an estimate based on geoid model use. I feel that this sort of information is source metadata and not part of the CRS. Is the purpose so that when the data is transformed back to HAE that the same transform will be used? If not, I wonder what the purpose is. If this is ok, should we allow annotation of whether static carrier phase or RTK was used, receiver and antenna brand, observation intervals? There might be biases that later become understood, and this information is helpful in estimating the variance. Where is the boundary in terms of how information about how coordinates was obtained between things that can be annotated in a CRS expression and things that can not or should not be annotated? An alternative view is that 5703[GEOID12B] is a *different CRS* from 5703. I lean to this somewhat. To deal with the various different CRSs created by this view, it feels like an ensemble situation. We should then have 5703, NAVD88(original), and then a variety of NAVD88(GEOIDnn), all within some NAVD88(ensemble). It would be interesting to see what NGS says about whether it is reasonable to consider NAVD88 obtained by a particular geoid model as a distinct reference frame. I suspect they'd say that no, there is one frame, and they have published successive transformations that they believe to be increasingly accurate. I also wonder about the differences in coordinates obtained by varying reasonably modern geoid models compared to the uncertainty in HAE. Personally I have decided to store observations in EPSG:6319 (without a compound orthometric height, so that HAE is stored), because I can compute NAVD88 later when I want to, and it feels cleaner to store data closer to what was observed. Plus, I expect that NAPGD2022 will be released within my lifetime, and 6319 HAE to NAPGD2022 seems more straightforward then transforming from NAVD88. However, my vague perception is that my approach is odd. It's interesting about 'many users' it would be interesting for them to write here and explain their situation and how this annotation works, with an analysis of estimated errors. _______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
