Hi Greg,
Comments inserted below -
-----
Cheers, Spring
On 08/Mar/2021 08:36, Greg Troxel wrote:
[I'm not sure how on-topic this is for qgis-user, but I'm guessing it's
relevant enough, at least until a Moderator comment otherwise.]
You're right but I took my que from other GPS related threads and lack
of response from Trimble.
Springfield Harrison <stellar...@gmail.com> writes:
To figure out what's going on this description needs to be tightened up,
which is probably going to require trimble documentation or support to
clearer (maybe the docs are fine; I haven't looked).
I'm familiar with the docs and no help from Trimble.
For many years my work flow has been:
Trimble Receiver + RTCM/SBAS ->
This is unusual phrasing. SBAS is a class of things, not a particular
corrections source. I'm guessing you are in North America and this
really means WAAS.
RTCM is a family of protocols for transporting corrections. I am
unclear on whether the WAAS format uses RTCM but I don't remember seeing
it. Within RTCM there is RTCM2, usually used for pseuorange
corrections, and RTCM3, usually used for carrier phase reference data.
So I wonder if the ProXR is doing RTK, what the correction source is,
and what the distance to the base station is (or if it's VRS).
To me the most important thing to be precise about is pseudorange
solutions (often called navigation solutions) vs carrier phase solutions
(post processed or RTK). Then, there's PPP which is harder to
understand.
So I think you mean that while you were collecting points the receiver
was calculating pseudorange solutions and using the pseudorange
corrections delivered by WAAS.
Yes! I use SBAS because Trimble does in TerrasSync but it does mean
WAAS in southern BC, I think. They don't use WAAS because the SBAS may
use a different correction source elsewhere in the world. I enable
carrier measurements in TerraSync most of the time.
Again, following Trimble terminology, RTCM in this case is a marine
beacon. I have no source for RTK.
Pathfinder Office [+ RINEX Post Processing] -> SHP files -> GIS (QGIS
or Manifold GIS).
You say "RINEX Post Processing" but that leaves out a ton of important
details. I am guessing you mean that the receiver records carrier
phase observables, and then there was a double-differenced carrier phase
solution for each ooccupation. The obvious question is where the
reference station data is coming from, how far away it is (or is it some
VRS), and what datum the reference station coordiantes are in.
Or maybe this is doing PPP. There, similar questions apply about where
the orbit data is coming from and what frame that is in.
I use the Pathfinder Office Post Processing engine which looks after the
technical details. I select a base station from their provided list,
sorted by distance and it fetches the (RINEX?) files and applies the
corrections. I think the distance was about 30km. PFO makes no
provision for specifying or modifying the base station CRS. It is
encoded in the RINEX files. It will utilize carrier phase data if it
available in the rover file.
The CRS is NAD83 UTM 10N throughout, for my home area at least.
There are many realizations of NAD83. Anything you did last year is
likely in "NAD83(2011) epoch 2010.0" if you are in the US and firmly on
the North American plate, and in Canada likely in NAD83(CSRS) apparently
in a province-dependent epoch. The recent realizations are close enough
that neglecting this won't hurt too much, but if you are going to call
1m an error rather than a match, you should be careful about this.
My concern is not the absolute error but the systematic shift of all the
points to the NW; the precision seems quite good, it is the accuracy
that I question. I think the different flavours of NAD83 UTM zone 10N
differ by centimeters at most (?)
If you are in an area with ground motion (e.g. Pacific Plate) then you
have a lot more to do.
I am but how is this relevant, this is mm per year?
The other big thing that's missing is what the trimble software is doing
about datum transformations (or not, if the reference station
coordinates are in NAD83(2011) as I'd expect).
Datum transformations where? Their post processing process is "under
the hood", QGIS datum transformations are much the same. I have some
faith (but not total) that they are being handled correctly. This is
supposed to be mapping, not geodesy.
None of these steps offer any option to choose or modify the Base
Station CRS so I don't think that would be the culprit in my NW
data offset, although maybe I've missed something.
I think it's necessary to understand what's going on inside the software.
Maybe, but that would be Trimble proprietary stuff, presumably. Their
intent is to provide a streamlined workflow that incorporates all the
myriad technical gymnastics but only exposes me to the NECESSARY
details. I'm sure that research grade differential software would
reveal most of the operating parameters.
Last fall I collected quite a few points in an attempt to
quantify the problem, if that's what it is. Here are some
summaries:
As Nicolas said, you are talking about "known" but have not explained
where those coordinates came from and their expected errors. I also
can't figure out your color scheme, and whether you are measuring 2
marks or one, etc.
I'm sorry but the presentation is complex and not overly clear. This was
not intended for presentation so lacks certain clarity. I can't give it
much more time but do appreciate the time that you and others have
spent. Both MAP B and Map A are referencing one point (each).
Positioning of the known source for Map B is from the orthophoto which
is not always reliable, although I think it is in this case. However,
Map A uses the property cadastre for reference which does fit the
orthophoto very well (actually the other way around). Both situations
are very comparable. *The thing to note is that the GeoXT points are all
clumped closely together implying precision but are removed from the
actual point implying lack of accuracy. * This is the puzzle. Truly
imprecise results would be more scattered.
Data from the receiver in no-differential pseudorange solutio mode (not
sure what "uncorrected" means) is going to be in WGS84(G1762), probably
labeled as WGS84, which is different than NAD83(2011), and that needs a
datum transform. In QGIS, that often ends up with a null transform,
which is wrong. So there's a good question about what is going on
within Pathfinder Office with datum transforms, which you need to find
out from Trimble docs or support.
Uncorrected means just that, no real time corrections or post
processing. Wherever I have control over the CRS, (receiver, PFO export
to SHP and QGIS) I specify NAD83 UTM zone 10N. Beyond that, the
translation is not in my hands. I don't know exactly what PFO or QGIS
are doing under the hood but make the best choices wherever they give me
an option.
Thanks very much for these questions, a good learning experience for
sure . . . .
_______________________________________________
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
