[Qgis-user] Trimble GeoXT 2005 Accuracy

[Greg Troxel]

Springfield Harrison <stellargps at gmail.com> writes:

> I recently acquired a Trimble GeoXT 2005 Series and am puzzled by the
> results it produces:
>
> 1. Compared to a variety of "known" points, it consistently records
>    positions that appear to be in error by 1.2 - 1.5 m NW from the
>    known point.
> 2. Points are collected and then mapped in QGIS as NAD83, UTM Zone 10 N.
> 3. The known points include property survey pins, Government control
>    survey monuments, Total Station survey points derived from the
>    above, other GPS results (Trimble ProXRS) and identifiable points on
>    orthophotos.
> 4. I'm using SBAS correction in the GeoXT.
>
> It appears to be adding a consistent offset to the GPS result although
> no offset has been set in TerraSync.
>
> Many thanks for any thoughts on this situation . . . . .

I'm really not clear on what this particular receiver is purporting to
do, but a consistent meter-ish offset smells like an incorrect datum.

If you are using SBAS and in the US, that means WAAS.  So you are
getting results that in some CRS that the list hasn't figured out what
it is, but "ITRF2008 current epoch" is my best guess.  That's
essentially equal to "WGS84(G1762) current epoch".

Those frames are definitely not equal to any flavor of NAD83.

qgis, via proj, will treat "WGS84"  and "NAD83" both as datum ensembles
and because each ensemble has a low-accuracy member treat them as equal,
and thus choose a null transform.  IMHO this is the wrong thing to do,
as WGS84(G1762) and NAD83(2011) are both datums with high intrinsic
accuracy and are definitely not  equivalent.

Converting from ITRF2014 to NAD83(2011) will apply a datum shift.

Advice 1 is to shift your project CRS from NAD83 to ITRF2014 and see if
the relative position of the observations and controls changes.   If so,
you have datum transform trouble.

My real advice 2 is to take the data file from the unit and label it as
ITRF2014, and then see how things line up.  If you are talking about a
meter you need to really pay very close attention not only to datum
labeling but also in understanding the transformations your software is
making.

Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20210306/e83d8312/attachment.sig>