Saber Razmjooei via QGIS-User <[email protected]> writes: > Hi Jim, > > Here is a full article on how projections (specifically the British > National Grid) work in QGIS and what you can do to improve your data > collection when using on-the-fly transformation: > https://merginmaps.com/docs/gis/projections/#projections
Thanks for writing, posting and pointing that out. It's a great overview for people who are completely unclear on the concept. A few comments: A nit: this is very out of date: Most importantly, the recent release of QGIS 3.16 LTR and QGIS 3.18 for all platforms is on PROJ6+ version. and it's also unclearly talking about official binary packages vs qgis source, and indirectly makes claims about random other packaging systems (QGIS does not release binaries for "all platforms" :-) that may or may not be true. This blurring of source code and official binary packages for a limited subset of platforms is a general problem, not specific to your comments. The real reason I wrote is because of promoting the concept that GNSS receivers output data in 4326. The page says However we want to capture point by GPS receiver in the field by Mergin Maps mobile app, and we add a point layer in WGS 84 coordinate reference system. Everybody does this, but it's wrong. No receiver outputs in the ensemble, and if the GPS receiver 1) was really a GPS receiver, not a multi-constellation receiver and 2) was computing autonomous positions, with no SBAS, and no RTK, then it would be in today's recent WGS84 realization, WGS84(G2296). Labeling positions with the ensemble at best adds 2m of uncertainty, because WGS84(TRANSIT) is substantially different from the rest. (I realize that in your AU example, no SBAS is a fair assumption. But not in US or EU.) As for point 1, I've never seen a straight answer about what any GNSS receiver does in autonomous/SBAS mode to combine the constellations, which each have their own CRS! If the GNSS receiver is using SBAS (EGNOS or WAAS), then the positions it outputs are *no longer in WGS84*. They instead are in the SBAS reference frame. I am guessing that's ITRF2008, 2014, or 2020 now, but it's remarkably hard to find that documented. Using the WGS84 ensemble causes proj to be ok with null transforms. The path from 4326 to 27700 involves 4326 to ETRS89, which in the pipeline you showed assumes equivalence. I asked proj for a transform from EPSG:7912 (ITRF2014) to 27700, expecting to find a more careful transform to some ETRS89 realization before using the grid file. Instead, I got a ballpark transform, which is very likely worse. I'm not really sure why, other than perhaps that's in the EPSG database, which feels like a bug if so. The point I was trying to make can be seen from projinfo -s epsg:4326 -t epsg:4258 projinfo -s epsg:7912 -t epsg:4258 The first is a null transform, and the second (from ITRF2014) is not null. Probably, transforming from the WGS84 realization in use, or from ITRF2020 as a proxy (for either recent WGS84 or what SBAS is using) to ETRF2000, and then from ETRF2000 to OSGB36 is the best approach. Of course, the idea that coordinates from autonomous or SBAS are better than a meter or two is not credible. Now, RTK equipment is sub-$1K. But, RTK systems never output in 4326, and they are usually in a regional/national static datum, 'NAD83(2011) epoch 2010.0' in the US, and apparently ETRF2000 in the UK (at least centipede-rtk.org uses that, and with my limited understanding of EU geodesy, it seems like the right decision). Overall, I think we should refrain from telling people that data from receivers comes out in 4326, at least without cautioning them that they're adding a 2m error source to their positions and that having done so, they don't get to complain that points whose apparent coordinate errors are <= 2m are "off". Greg _______________________________________________ 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
