CORS data offset pr...
 
Notifications
Clear all

CORS data offset problem

13 Posts
7 Users
0 Reactions
5 Views
 Dino
(@dino)
Posts: 6
Registered
Topic starter
 

Hi Guys!

?ÿ

I have a few 15h observation rinex files from 6 different CORS stations.

When I tried to compare the absolute position of CORS with the computed position from PPP (AUSPOS, CSRS),

there is a consistent differences in long and lat, not the ellipsoidal height.

The offset for Easting is 70cm and Northing is 65cm

Is there any problen with the absolute position of the CORS station?

?ÿ

Thanks!

?ÿ

 
Posted : September 5, 2020 9:35 am
(@bill93)
Posts: 9834
 

I know nothing about datums in the UAE, but wonder if you are comparing values in different datums.

 
Posted : September 5, 2020 10:05 am
(@jitterboogie)
Posts: 4275
Customer
 

Are you collecting Raw data or are seeding your project control points by entering a know and held value??ÿ I did some work over there a few years ago, and didn't see that kind of displacement.?ÿ Problem is unless you have a good accepted and verified and calculated point of reference, your data is always going to be an autonomous observation until you can tie it down to a real world value that was proven.

 
Posted : September 5, 2020 10:35 am
(@loyal)
Posts: 3735
Registered
 

Absolute Position?

What does that even mean? I would submit that "absolute position" is a contradiction in terms (oxymoron). Inasmuch as EVERY point on Earth is "moving" at all times (some more than others obviously), ANY "coordinate" value (Latitude/Longitude/EH, X/Y/Z, whatever), is a best a snapshot in time. Local Datums like NAD83 are an effort to minimize relative velocity of "points" within the area covered by the Datum, but there is still SOME movement (coordinate change) over time.

The coordinate values PUBLISHED by the IGS/NGS (and others) are at best, estimations of where a given point WAS at a given time, and relative to a given Datum (reference frame etc.) That said, these values ARE the values that we should be using for most things spatial.

I know this is somewhat off target (out in the weeds), but some of the terminology used by Surveyors kinda makes me nuts sometimes. We all say/write/think things that are "technically" off base at times (much of the time for me, but I'm OLD).?ÿ

Oh yeah...get off my lawn!

?????ÿ

 
Posted : September 5, 2020 11:36 am
(@john-nolton)
Posts: 563
Registered
 

@bill93

Well if I wanted to have a little information on UAE I would look at Photogrammetric Engineering & Remote Sensing

Vol. 85, No. 2 Feb. 2019, pp 87-88; (just saying).

JOHN NOLTON

 
Posted : September 5, 2020 2:58 pm
(@geeoddmike)
Posts: 1556
Registered
 

I am not certain what the original poster is comparing. First he indicates that he has a 15h observation data from six different CORS. Does this mean that he downloaded from the NGS GPS data observed at the CORS and then submitted these files to AUSPOS and CSRS-PPP??ÿ

He further states that he compared the computed positions to the ƒ??absolute positionƒ? for the CORS. He does not state the source for the ƒ??absolute position.ƒ? My best guess is that he is comparing the results to the CORS coordinates on the NGS site. A sample of the coordinate file is here: https://geodesy.noaa.gov/cgi-cors/CorsSidebarSelect.prl?site=nvtp&option=Coordinates14

As the coordinate file from NGS provides coordinates in both ITRF 2014 (epoch 2010.) and NAD 83 (2011) epoch 2010.0, perhaps the original poster could indicate the source for his ƒ??absolute position.ƒ?

Looking at the sample solution file at the CSRS-PPP site, I see that it provides NAD83 (CSRS) epoch 1997.0 coordinates. NOT the same as the US version of NAD 83. Remember as well that NGS OPUS solutions are provided at the date of observations and not at the reference epoch. The CSRS-PPP also uses a different velocity field. Coordination is underway between the US and Canada on the new North American datum.

In addition to possible differences due to version of NAD 83, differences between positions at the reference epoch and date of observation, and possible velocity differences during position updates, did the data submitted to the tools include the correct antenna model and type as well as the ARP height?

I have not revisited the AUSPOS tool at this time.

My reading of his post leads me to believe that no observations at his location were made.

I could have completely misunderstood the original post. It would not be the first (nor likely the last) time.

Perhaps @Dino would clarify?

?ÿ

?ÿ

 
Posted : September 6, 2020 2:28 pm
 Dino
(@dino)
Posts: 6
Registered
Topic starter
 

@bill93 long lat should have almost the same value

 
Posted : September 11, 2020 12:51 am
 Dino
(@dino)
Posts: 6
Registered
Topic starter
 

@john-nolton Thanks, I have read through the document

 
Posted : September 11, 2020 12:52 am
 Dino
(@dino)
Posts: 6
Registered
Topic starter
 

@jitterboogie those rinex files are taken from permanent cors station, I am using those rinex files for ppk correction

 
Posted : September 11, 2020 12:54 am
 Dino
(@dino)
Posts: 6
Registered
Topic starter
 

@loyal those are permanent cors station rinex file. In theory those rinex file should have the identical value after processed through PPP

 
Posted : September 11, 2020 12:57 am
 Dino
(@dino)
Posts: 6
Registered
Topic starter
 

@geeoddmike Yes, you're right! I submitted cors rinex for PPP processing.

Those cors rinex files (and coordinates) are provided by authority, for our drone ppk processing

The antenna model is given, and may be cors are using different reference epoch

 
Posted : September 11, 2020 2:02 am
(@john-hamilton)
Posts: 3347
Registered
 

Two words...EPOCH DATE

 
Posted : September 12, 2020 6:50 am
(@geeoddmike)
Posts: 1556
Registered
 

@dino

For what itƒ??s worth, in 2012 I assigned a lab to a class I taught involving the use of automated tools and their comparisons. While dated it might be useful. See: http://geodesyattamucc.pbworks.com/w/file/fetch/141316527/lab9_2012_solutions_v2.pdf?force_download=1

It was my model for the studentƒ??s solutions. Note that it includes outputs from various tools not only the automated processors. In particular there is an example of the output of the Horitzontal Time Dependent Positioning tool (HTDP) using a US NAD83(2007) epoch 2002.0 to IGS08 epoch 2012.085.

Note as well the NGS OPUS Solution Report that provides both NAD83 (2011) epoch 2010 and IGS08 epoch 2012.086 coordinates in its solution.

The fact that NAD83 is not geocentric at the ~2.5 meter level and ITRF/IGS is geocentric accounts for the large magnitude differences in these coordinates. The actual difference depends on where you are on the earth.

Note the magnitude of the (default) velocities in the HTDP output. The velocities reported: 1.57, 0.49 and -0.49 (mm/yr) ?ÿin X,Y and Z respectively will not result in the magnitudes you report in original post.?ÿ

The lab did serve its purpose but I note a few errors and inconsistencies which I leave to readers to note.

In closing, remember that NAD83(CSRS) and the US NAD83(2011) are NOT equivalent. Perhaps someone knowledgeable about the issue might chime in.

By the way, there is a NASA tool AAPS which does provide kinematic PPP. I have not revisited the site which should be easy to find via a good search engine.

?ÿ

Good luck with your work,

?ÿ

DMM?ÿ

?ÿ

 
Posted : September 12, 2020 9:28 pm