I have vector data expressed like this:
e-baseline n-baseline u-baseline sde(m) sdn(m) sdu(m) sden(m) sdnu(m) sdue(m)
819.6813 -269.8529 -20.7567 0.0009 0.0014 0.0031 -0.0003 -0.0020 0.0005
I can convert the delta E,N,U to Delta X,Y,Z using NGS's forward3d program, but how do I interpret the weighting information? In Star*Net I would probably want to treat it like a vector with no supplied weighting, and change the the default standard error for each vector like this:
.GPS DEFAULT [VALUE] [PPM] VERT [VALUE] [PPM]
G1 FROM-TO DX DY DZ
How would you go about computing the default standard errors and ppm for the above data lines from the sde,sdn,sdu etc,?
Or should I just guess based on the other quality indicators and spare myself the effort?
10 years ago I had to purchase GPS units. I test drove 2 brands. One software the user had to apply weighs to vectors the other was plug and play.
I tested them on County GPS points (3 sets of GPS points) the plug and play hit the county data within 0.01 ft all 3 times. We had to play with the other to get the same results - time consuming having to continually rerun the data and record each input and results to get the best.
Saving a hour on reprocessing data multiple times for all the sites I have done is priceless.
I'm not sure what you mean by "plug and play". I am adding static baselines to a least squares survey network adjustment - the data has to be weighted somehow. My question is do I assign them standard errors based on my typical results or do I attempt to calculate them from the atypical data provided? To be honest, I have already done the former and shipped the data off, but would like to be able to do the latter. Correct weighting is the key to getting honest adjustment statistics.
> I have vector data expressed like this:
>
> e-baseline n-baseline u-baseline sde(m) sdn(m) sdu(m) sden(m) sdnu(m) sdue(m)
> 819.6813 -269.8529 -20.7567 0.0009 0.0014 0.0031 -0.0003 -0.0020 0.0005
If all of your standard errors are of the same magnitude as the sample above, adjusting the vectors may not be worth the effort -- they're already below noise level for the technology.
That said, it seems to me that the standard errors in the east, north and up directions can be treated just like the baseline components, i.e. run them through the same conversion (FORWARD3D) to get the X, Y and Z standard errors.
The correlations are another matter, and I don't know how to handle them.
Howdy,
To transform the linear units from LGH to XYZ we use rotation matrices. See the equations in the following presentation or do a web search.
http://geodesyattamucc.pbworks.com/f/Lecture14–MoreDamnedMathematics.ppt
Note the requirement to have the latitude and longitude of the standpoint (origin) of the vector. The geodetic coordinates should be in radians.
I am surprised that you were not provided the values in the XYZ system. You realize, of course, that the formal statistics are too optimistic. But that's another topic....
Cheers,
DMM
Thank you very much. Based on that, and based on the fact that I would have to scale those errors way up - like you say, they are too optimistic - I think I will spare myself the effort and assign them reasonable weights based on past experience. I would just be using trial-and-error to determine by what factor to scale the errors anyway...
Thank you again for the advice and education.
Why dont you use your GPS software to solve the Static vectors as NE points and then import them into Starnet . I dont see the point of using Static Vectors . The GPS software already solves the vector using LSQ . Bring them in as NE Points as Jim said . Thats how I do it .
> I dont see the point of using Static Vectors . The GPS software already solves the vector using LSQ.
It solves them using only the information available to it, and then assigns (notoriously optimistic) standard errors to them. In order to effectively combine GPS and terrestrial data in a single adjustment, you have to have realistic errors associated with all the measurement values, which is the reason Star*Net allows you to assign scalar values to the vector components.
I thought that "weighting" was the error estimates of the equipment?:-S
> I thought that "weighting" was the error estimates of the equipment?:-S
Not necessarily a weighting scheme can be derived from any number of conditions, be it atmospheric, equipment, operator etc. I believe the weighting scheme is based on the error estimates of the measurement/observation and the equipment is just one consideration.
"Sometimes, what we are most interested in is not the absolute magnitude of observation errors, rather the
relative accuracy of observations. According to the relative accuracy of di¤erent observations, we assign
each observation a positive number, called weight. The smaller an observation error is, the more accurate
the observation will be and consequently the bigger weight the observation should have."
--Fan 2010
Dear Hillbilly Leg,
I have a short answer and a long answer to your problem.
Short answer first --
Yes, indeed, those error estimates are way too optimistic.
So you should seriously consider more realistic weights.
The downside is that GPS is usually less accurate in vertical
than in horizontal. And, that is difficult to portray with
a "rule of thumb" in XYZ coordinates without a little math
and those darned covariances.
Long answer --
This is how to do it formally. First, download the documentation
for program ADJUST. We don't need to run it -- but the docs have
the equations we need.
Warning: long URL
www.ngs.noaa.gov/PUBS_LIB
/Adjust_TheHorizontalObservationAdjustmentProgram_TM_NOS_NGS_47.pdf
OK, the core formula you need is 3.21 on pg.33.
This is a matrix equation for linear error propagation.
It is also how you transform variances and covariances between
different coordinate frames.
The big sigma on the left is the output 3x3 variance-covariance matrix.
The big sigma on the right is the input 3x3 variance-covariance matrix.
The G is a transformation matrix (also 3x3) built from rotation matrices.
(You'll also need the transpose of G)
Note: eq. 3.21 is more complicated than the simple vector rotation
x = R(transpose) g
where x is a 3x1 column vector in the XYZ frame, and
where g is a 3x1 column vector in the NEU frame, and
where R is a 3x3 rotation matrix [as is R(transpose)]
What this means is that you can *not* just use FORWARD3D, which
implements the simple vector rotation. We need 3.21.
OK, since you are starting in NEU and headed for XYZ, the G we
need in 3.21 is R(transpose). If you were in XYZ and going into
NEU, then the G would simple be the contents of R.
So, you wind up computing
Cov(XYZ) = R(transpose) Cov(NEU) R
For R, use equation 3.3 on pg. 30. The phi's and lambdas are
geodetic latitude and longitude. Longitude is positive East.
Be careful, your sigmas will need to be converted to variances.
And, your sigmas are ordered ENU instead of NEU. I don't know how
to describe the "sden(m) sdnu(m) sdue(m)". Does this mean they
are reporting the square root of a covariance? (the statistician
inside me shudders). Anyway, check to see if they are reporting
an honest-to-God covariance or its square root.
Anyway, now it's just plug and chug.
Hope this helps.
Yell if you have more questions.
Dennis
Thank you everybody for the advice. The point behind this exercise was a test of a baseline processor I had not used before. I was satisfied with the results (as borne out by the network adjustment using my best-guess weighting) but wanted to see if I could maybe make use of the supplied standard errors. I am a little bit math-challenged, so I think now I won't.
Errors That GPS Software Does Not Cover
1/ Plumbness of antenna rod?
2/ Centering of antenna rod?
3/ Antenna height measurement error?
4/ Are all antennas pointing North?
5/ Comparative precision?
1 & 2/ I use fixed height rods with 3 legged bipods. Sometimes when I return I find the rod point has popped off the observed point. If the point is 0.05' NW then the antenna is about 0.05' SE. But I have no clue how when during the observation it occurred. Note it and figure out later if it was a problem.
3/ My fixed height rods have a point. If I set up on/in a pipe my antenna height can be 0.04'-0.08' long. Again I note it and figure it out later. On most of my projects where elevation is critical, my GPS is on mag nails in pavement or curb. Height is less critical. Suppose however even if you are not concerned with elevations, if you observe a pipe with a fixed height rod and later occupy it with GPS on a tripod, the antenna heights from the fixed point are off. When GPS software tries to resolve with a wrong antenna height at a multiply observed point it can actually displace other points horizontally.
4/ I have yet to notice a problem since I do setup North. I have never intentionally tested against miss-aimed antennas.
5/ Generally this is a canopy/view issue. GPS software reports the number of satellites used in each vector solution. Assume three points, A, B, C with C under canopy. Vector A-B may be 8-9 satellites, vector A-C 7 satellites and vector B-C 6 satellites. The canopy removes satellites from the solution. A skewed skyview can skew the position. While the software may report a favorable mathematical position the unbalanced satellites can actually shift that position from true. Here it is strictly your judgement on allowable error.
I suggest using NEU coordinates from your GPS software into a different LS routine. Personally I start at Horiz error 0.02' and Vert error 0.04'. If my GPS is per repeated OPUS-RS solutions I will make my Vert error 0.02'. With 3 GPS points the fit is almost always within the error budget. At 5 GPS points I almost always expect 1 outlier.
Paul in PA
>> http://geodesyattamucc.pbworks.com/f/Lecture14–MoreDamnedMathematics.ppt
It is scary to me to think that I might understand this at some point in my education/career!
