[Qgis-user] Trimble GeoXT 2005 Accuracy

[Springfield Harrison]

Hello Greg, thanks for your notes.  I think it involves Datum issues, as 
you say.  It seems to be very murky.

My assumption (now it seems likely wrong) was that SBAS (WAAS in 
southern BC?) would "adapt" to the CRS designated in the receiver 
(NAD83, UTN 10N) and was also localized to the field location (as in 
Wide Area).  Thus QGIS would see the resulting NAD83, UTM 10N SHP file 
as compatible with the project CRS in QGIS (EPSG:26910, NAD83 UTM 10N).

I'm not sure why I would need to know or use the SBAS Reference Frame 
although the receiver certainly would.

Changing the project CRS to ITRF2014 (there are 3!, WTF, I used 7912) 
didn't change anything.

I've since deferentially corrected the data with mixed results, some 
better, some worse, relatively.  I need to look at that further.

Anyway, if Pathfinder Office produces a NAD83 UTM 10N SHP file from my 
SSF file (NAD83 UTM 10N), should that not project happily in QGIS set to 
EPSG:26910?  I think the datum transformations would take place in the 
receiver (in concert with SBAS) and Pathfinder Office.

Perhaps there is more to this, I certainly appreciate your thoughts . . . .

-----
Cheers, Spring




On 06/Mar/2021 05:53, Greg Troxel wrote:
> 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