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 <stellar...@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
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
