Activity Feed › Discussion Forums › GNSS & Geodesy › Reference position in Rinex file
Reference position in Rinex file
Posted by bill93 on November 13, 2015 at 8:01 pmIt’s my assumption that the Reference Position in the receiver or the Approximate XYZ in a Rinex file is an initial guess at the position to start the refinement process and has no other purpose. I can set that to some reasonable value any time before submitting the file to OPUS.
Or am I wrong, and changing it in the receiver during an observation session, or by editing the Rinex, would affect the integrity of the data?
RCliffWilkie replied 8 years, 5 months ago 6 Members · 5 Replies- 5 Replies
You won’t hurt anything by changing it. Usually it is the C/A code position. It may be a reference position input before the session starts. Some translators will scan through the file and compute a point position based on all of the data (or some of it). others may just take the first position in the file (which may be iffy, or an old position). A lot of the CORS have their accurate (i.e. adjusted) position in the header, but not all. One of the first CORS, GAIT, had an incorrect position in the header for years that was off by 600 m (or maybe it was 600 feet?). I know of a large city GIS that was using that to correct their GIS data (code handheld), and used the wrong position for a lot of data. They didn’t find out until they tried to overlay on a map.
OPUS does not use the Approximate Position. So it does not make any difference.
This was recently pointed out to me and I did not believe it. So I went back and found several occupations that failed. They had bad initial conditions, however after some inspection I realized that they also had about 50 seconds worth of garbage data at the start of the file with completely missing epochs. Trimming the first minute off of each of the files AND leaving the errant position intact resulted in the files processing.
So I now believe it. OPUS does not use the approximate position from the RINEX header.
m
It is my understanding that OPUS uses the reference position to select the nearest CORS with good data. However OPUS-S can solve with almost any combination of nearby CORS. I have tested solutions from CORS as far away
as 1,000 miles. At that distance you have to be careful about the commonality of GPS satellites.I know definitely that OPUS-RS uses it and it puts a limit on how far away it will go to use a CORS. Years ago I had 2 simultaneous occupations submitted to OPUS-RS one solved without comment the other was reported as “Outside the Polygon” I contacted NGS and received a reply that the second had a bad reference position. I used my outside the box solution XYZ and resubmitted. My solution came back inside the box and with the same list of CORS as the first. I had not allowed my receiver to get settled in with a good position and it used a position from a job a few days earlier and substantially far away. OPUS-RS pre-solves the atmospheric correction for the reference position. With a substantially different reference position your correction could be less desirable. It also uses the reference position to determine if you are Inside the Polygon.
Occasionally I have submitted a simultaneous OPUS-RS files with one being substantially longer and gotten back solutions with one different CORS. I have tried to resubmit by forcing a CORS and OPUS-RS says there is a data problem. Apparently the longer file ran into a time where that particular CORS had poor data. Over the years I have pretty much learned to do as much right as I can and accept what I get. OPUS-RS will use up to 9 CORS and on occasion I have gotten a solution with only 7 or 8, especially if I submit soon after occupation. When I am checking out OPUS-RS files from other surveyors I have gotten back solutions with as few as 3 CORS because that is all that is close and good. I do not have that problem in eastern USA with an abundance of CORS. Sometimes when I have time on my hands I will resubmit a 9 CORS solution, exclude those 9 and get back a solution with 9 different CORS all still within range.
Paul in PA
OPUS uses the approximate position to select CORS Stations. One of our LEICA GS15 receivers came with a default position is Switzerland. We collect data in the RRNEX format. It always selected 3 CORS Stations in Eastern Europe. When I go in the RINES file and edit the XYZ position, it selects the local CORS and gives a slightly different solution. We only used it for long sessions when we discovered that so common satellites was not a problem.
For what it is worth: RINEX header positions are not always a pseudorange or some type of “approximate” position. The RINEX data that one gets online from the German Real Time Network (Now called GREF) has their high-accuracy position in the header of the RINEX file. Or at least it used to be when I was using it over ten years ago.
Log in to reply.