GNSS Solutions

Wednesday, August 25, 2010 10:54:32 PM

Hey Loyal,

Using the IMPORT tab on the left hand side.  And then select Internet Download.  Then the Internet Download 3.10 window opens and then I select NGS for the provider and select the 2 CORS (Continuously Operating Reference Station).  For this project I used  Stations LNC2 and PLSB.  

Give me a couple of minutes.  I am having some technical difficulties doing a simple screen shot on my PC!!!  I can do a quick sketch in Microsurvey with the vectors.

Loyal, do you use GNSS Solutions often?  I can send you the data if you like.

Get back to you in a few and thanks for your prompt response.

Nick

When adding a CORS site it is easiest to use the ITRF XYZ values.

I have done that without any problems, so I would hesitate to do it any other way.

 For new sites 0 acceleration is AOK.

Paul in PA

 

Here's what I am talking about concerning the NAD83(CORS96) Epoch 2002.0000 positions on the two CORS identified above:

 

| NAD_83 (CORS96) VELOCITY LNC2 |

| Transformed from ITRF00 velocity in Mar. 2008. |

| VX = -0.0030 m/yr northward = 0.0083 m/yr |

| VY = 0.0085 m/yr eastward = -0.0070 m/yr |

| VZ = 0.0061 m/yr upward = -0.0006 m/yr |

 

| NAD_83 (CORS96) VELOCITY PLSB |

| Transformed from ITRF00 velocity in May 2006. |

| VX = -0.0067 m/yr northward = 0.0087 m/yr |

| VY = 0.0106 m/yr eastward = -0.0113 m/yr |

| VZ = 0.0068 m/yr upward = -0.0000 m/yr |

 

If you use the NAD83(CORS96) Epoch 2002.0000 Coordinate estimates with TODAY's vectors (even IF you rotate and scale them to NAD83), you are in effect mixing apples and oranges.

 

Today's epoch is ~2010.6562, so 2010.6562 – 2002.0000 = 8.6562 (years), and:

 

0.0083 x 8.6562 = 0.0718(m) North @ LNC2

-0.0070 x 8.6562 = -0.0606(m) East @ LNC2

-0.0006 x 8.6562 = -0.0052(m) Up @ LNC2

 

As opposed to:

 

0.0087 x 8.6562 = 0.0753(m) North @ PLSB

-0.0113 x 8.6562 = -0.0978(m) East @ PLSB

-0.0000 x 8.6562 = -0.0000(m) Up @ PLSB

 

So...what you might be seeing in your solution (and one of the reasons you are having problems with the Chi Square test), is that there is about 4 centimeters of [predicted] differential movement (relative to Datum) between these two CORS over the last 6.5 years.

 

Couple that with the vertical variation (nearly 11 centimeters) on PLSB (see the 60 Day Time Series @ ftp://www.ngs.noaa.gov/cors/Plots/plsb.gif ), and even though your vectors might be perfect, they simply don't “add-up” to the spatial relationship that the NAD83(CORS96) Epoch 2002.0000 Coordinate estimates are telling your program that they should.

 

Another thing! The coordinate and velocity estimates at LNC2 and PLSB are NOT created equal (IMO):

 

| ITRF00 POSITION (EPOCH 1997.0)                   LNC2             |
| Computed in Mar. 2008 using 788 days of data.                     |
|     X =  -2587856.092 m     latitude    =  38 50 47.43072 N       |
|     Y =  -4247828.931 m     longitude   = 121 21 01.97013 W       |
|     Z =   3979064.003 m     ellipsoid height =    5.844   m       |
|                                                                   |
| ITRF00 VELOCITY                                                   |
| Set equal to vel lnc1, adapted from 814 days of data in Mar. 2008.|
|     VX =  -0.0198 m/yr      northward =  -0.0058 m/yr             |
|     VY =   0.0078 m/yr      eastward  =  -0.0210 m/yr             |
|     VZ =  -0.0045 m/yr      upward    =   0.0000 m/yr             |

verses:

 

| ITRF00 POSITION (EPOCH 1997.0)                   PLSB             |
| Computed in May 2006 using 45 days of data.                       |
|     X =  -2624236.777 m     latitude    =  38 41 06.14562 N       |
|     Y =  -4238644.036 m     longitude   = 121 45 45.18455 W       |
|     Z =   3965079.450 m     ellipsoid height =   -7.612   m       |
|                                                                   |
| ITRF00 VELOCITY                                                   |
| Predicted with on-line HTDP ver 2.8 in May 2006                   |
|     VX =  -0.0235 m/yr      northward =  -0.0055 m/yr             |
|     VY =   0.0099 m/yr      eastward  =  -0.0252 m/yr             |
|     VZ =  -0.0039 m/yr      upward    =   0.0006 m/yr             |
HTDP v.3.0 predicts:
VELOCITIES IN MM/YR RELATIVE TO ITRF2000 
          PLSB                    
LATITUDE   =  38 41  6.14561 N  NORTH VELOCITY =  -5.02 mm/yr
LONGITUDE  = 121 45 45.18454 W  EAST VELOCITY  = -23.66 mm/yr
ELLIPS. HT. =     -7.612 m      UP VELOCITY    =  -0.60 mm/yr
X = -2624236.777 m              X VELOCITY     = -21.52 mm/yr
Y = -4238644.036 m              Y VELOCITY     =  10.19 mm/yr
Z =  3965079.450 m              Z VELOCITY     =  -4.29 mm/yr
This is pretty darn close agreement between HTDP v.2.8 and HTDP v.3.0, I'll bet money that the vertical variation indicated on PLSB (60 Day Time Series) is due to a UNREPORTED Antenna and/or Mount change. This is a real problem with many of the co-op CORS.

ftp://www.ngs.noaa.gov/cors/Plots/lnc2.gif

 

 

First, I would drop PLSB like a hot potato, and replace it with P271 (which is nearby). That way you have access to SOPAC Modeled Coordinates for BOTH of your CORS sites (although LNC2 only has a years worth of data so far in the SOPAC database, and therefore doesn't have a modeled position just yet).

 

Next, I would make sure that you have either the Rapid or Precise IGS ephemeris for your processing, AND I would use either the “day of observation” NGS Coordinate estimates (ITRF200) which YOU will have to calculate using the ITRF2000 velocity estimates AND the 60 Day Time Series, or simply grab the ITRF2005 “day of observation” estimates from SOPAC (via the SECTOR utility).

 

Do all of your “adjustment” in either ITRF2000(NGS) or ITRF2005(SOPAC), and once you get things where you want them, use HTDP v.3.0 to get from ITRF200x Epoch 2010.xxxx to whatever NAD83(CORS96) Epoch that blows yer skirt up. Oh yeah, use either the 60 Day Time Series rms values, or the Sector rms values in your LSA adjustment (thus making the CORS Coordinate Estimates partial fixities).

Loyal

Loyal, following this thread, if one gets OPUS created coordinates for control points on a site, how should the basis of bearing be labeled on a plan?
If the spc is the final product to be used is it the NAD_83(CORS96)(EPOCH:2002.0000)   or     ITRF00 (EPOCH:2010.6562) that should be listed?

John

 

John,

 

There IS a rotation variance between ITRF200x and NAD83(whatever). It will vary somewhat depending on where you are in North America, but in all cases, it is NON-trivial (IMO)!

 

Your “Basis Of Bearings” should be the same as your “returned” COORDINATES, and probably be stated in terms similar to the Examples in the NEW BLM Manual (or something along those lines).

 

The difference between NAD83(CORS96) Epoch [whatever] and another Epoch [whatever else] is going to be trivial (probably a few milli-arc-seconds at most).

 

Traditionally (as I see it), the “Basis of Bearing Statement” describes BOTH datum/realization (astro/assumed/magnetic/NAD??) etc. AND the methods used to determine it!

 

Loyal

Loyal, I am folloowing your posts here and in your Aug.22 post about CORS coordinates and the new NAD83(CORS96a) thread. Thank you for the info and education as it helps me understand the differences and movments of CORS.

So one should also list that the coordiante values were derived from static observations and processed through OPUS? (Forgive me for not having the new BLM manual at my diposal for reference- MA surveyor here).

 

Sorry bout that John,

 

I posted BEFORE I looked to see where you where!

 

I generally put a “table” with SPC-or-UTM-or-LDP and Geodetic Coordinate values (usually Geocentric XYZ) on my plats, with a statement as to where the coordinate estimates came from (OPUS, LSA, Network...), and how the geodetic values where transferred from my Primary Control Point(s) to the secondary/tertiary points (corners).

 

The Datum (and/or realization & EPOCH) are much more critical to the Coordinate Estimates, but somewhat less so for “bearings” (although one should not mix apples and oranges).

 

I don't (or try not to) do much in the way of “Land” Surveys anymore, so I tend to think more along the lines of the Metadata that SHOULD be included in Control Surveys. I don't think that a guy can really put TOO MUCH metadata on anything, but it's a fine line (sometimes) between “just enough” and NOT ENOUGH!

 

:)

Loyal

Thanks Loyal. I am always learning!

Keep up the good work,
John

Worry not about the fact you did not pass the Chi-Square test.

Far too many people look at that test as the sole indicator of whether or not they have acceptable data.  That is not a good idea.

It helps to understand what the Chi Square test actually does.  In non-mathematical terms all it does is test your data and the errors therein vs the errors you expected to find in the data.

So if you have really bad expectations and really bad data, you can pass the test.

If you have really good data and not so good expectations, you can fail the test.

In your case the section of report you post says this:


The fact your actual Chi square value is less than the lower limit indicates that the data is better than you expected.

Often when I'm teaching a class on the analysis and adjustment of data I'll have someone raise their hand with an objection.  "I never told the program how good I expected this stuff to be so how can the software possibly just what I expected?"

Turns out your standard errors are in fact telling the program how well you expect to do.  If you put in reasonable standard errors, good data should pass - exceptional data may not pass.  If you put in very lax standard errors, bad data can pass and good data will fail on the low side.

Most of the time when your standard errors are reasonable for your equipment, measuring conditions and personnel, data that does not pass contains either a blunder or systematic error.  Also, mostly under those circumstances you will find you fail the upper limit of the test by a very wide margin.  When that happens, it's time to find the blunder(s).

Larry P

Loyal, just so I understand correctly (the more I learn, the less I know) the final coordinates received from an opus solution are referneced to the day's epoch of collection?

AAhhhh, ok I get it. I can follow the use of HTDP to transform the coordinates of the reference stations used during the opus process, just wanted to make sure that the final estimates are 2002.0000 and not the days epoch.
i.e. the following excerpts from one I did yesterday and processed today with extended output:

======================================================================

The OPUS solution that you posted (see below) REALLY STINKS!

DATE: September 04, 2010
RINEX FILE: 0048246n.10o                            TIME: 13:37:32 UTC

Yes, I saw that also and multi-path was definately a problem on this site. I used this solution as a sanity check of RTN shots for part of an existing conditions survey. All hang-your-hat-on decisions were made with a total station and in the end will be rotated back onto the existing record plan bearing system for the final (per client's request).  This particular opus setup was on a MA geodetic survey disk I found out front and decided to set up on it. Neither MADPW nor NGS has a current datasheet or listing for the station though. I will be emailing my state dpw contact to see if they have an old "card" for the station.

I did break this rinex file up into three smaller files then sent to opus-rs. In the end I took an average of all including the rtn shots.

Wen I split it up and sent to opus-rs got better:
===========================