Stewart Holt <[email protected]> writes: > I will read your references to try to figure out whether WAAS is ITRF2008 > or 2014. But since the difference is millimeters, it is not really > important.
That difference is not important. The other question is epoch, and it seems pretty clear that for a frame like ITRF2008, what you get out of SBAS is "epoch of data", just like you do for non-differential GPS. This is a bigger deal in terms of the difference to some reference epoch than the frame shift. > My hope is to have a good CRS defined for SBAS in QGIS and that I think it's an incorrect leap to say "SBAS CRS". There are different systems and they probably have different frames. If you mean a "a table with a frame defined for each of the systems that are called SBAS as a group", sounds good. > null transforms are not used between CRS which are "just" a meter > different. When I save WAAS data as ITRF2008 (I can't remember which EPSG), > QGIS 3.16 thinks the datum is invalid. 2014 seems to be OK. There may well be other issues in proj and the database. The biggest thing going on here has nothing to do with obseessing over <1cm shfits in ITRF2008-ish frames. It's that proj 1) considers WGS84 to be an ensemble (fair) and 2) chooses a null transform if one member of that ensemble has an error which is large (always true, not a useful choice). As a user, the only approach I know of is to label recent GPS observations (>= 2013, in WGS84(G1762)) as in that frame, or in ITRF2008/ITRF2014. While not quite right, these labelings avoid the problems from saying "WGS84".
signature.asc
Description: PGP signature
_______________________________________________ Qgis-user mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
