[Qgis-user] Best practice when using UK national grid and GPS

[Greg Troxel]

Saber Razmjooei via QGIS-User <qgis-user at lists.osgeo.org> 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