Base File reductions and which post processor to use?

[James Suttles]

I have compiled base file reductions using DPOS and OPUS. I have broken them down into OPUS, JUSTIN and GIODIS.

I am confident the OPUS and GIODIS, use only GPS signals. JUSTIN I believe uses all available constellation data.

Is this the results that we should expect to see, and is one processor preferred over another. I know the OPUS solutions are not processed by DPOS, but its very interesting that the reduced coordinates are similar in one axis or the other, depending on the processor.

I feel that GIODIS with the 8 CORS stations in the reduction, is probably the most diverse solution. The elevation of GIODIS seems to be the lowest, with Justin elevations being the Highest and OPUS elevations being somewhat in the Middle.

So if setting control and using static files, which processor would yield the best real world coordinate, or are there too many variables to account for?

These are all 24 hour files collected at a 30 second epochs.

 

[Shawn Billings]

Great report, James. I did something similar several years ago with the Triumph-2.

Question: Were you concerned with the orientation of the receiver (also what sort of receiver was it)?

 

[James Suttles]

It's a Delta S3,
North is something to consider, but was not accounted for in this set of solutions.

I have checked some first order marks using the base and LS plus and the difference was roughly 0.03' horizontal and 0.05' vertical. Granted they were geodetic traverse stations and not GPS derived stations.

 

[Shawn Billings]

It's difficult to say which processor is best. It's interesting that the RMS reported by OPUS appears to be so pessimistic. I suspect that is because NGS can afford to set user expectations lower with the higher error estimates, since it's a free service and doesn't really have market competition. However with its higher error estimates the results are more consistent. This repeatability (i.e. precision) doesn't necessarily mean the solutions are more accurate, but it could. It's possible that there is some bias that would cause the results to be very consistent (precise) but to be off by some constant. The other thing to note is that the data being used isn't exactly the same, so the question is not only which processor is better, but also which procedure is better. The additional 3-5 CORS stations used by Justin and Giodis may be injecting additional error in the solution if the stations are not stable. The use of additional constellations may also provide additional error due to timing differences and other signal issues that are above my head.

So it may be that using only GPS or a combination of GPS and Galileo only is better than all constellations or that the three CORS are better than the eight.

Precision is definitely a very good place to start, but I believe once you are in the centimeter range deep questions start to emerge such as Pilate's famous question "What is truth?"

 

[Shawn Billings]

It's a Delta S3,
North is something to consider, but was not accounted for in this set of solutions.

I have checked some first order marks using the base and LS plus and the difference was roughly 0.03' horizontal and 0.05' vertical. Granted they were geodetic traverse stations and not GPS derived stations.

You're going to find it difficult to find something more accurate than what you have from your various solutions (any one of them) that you'll be able to "truth" against.

 

[nusouthsc]

I have compiled base file reductions using DPOS and OPUS. I have broken them down into OPUS, JUSTIN and GIODIS.

I am confident the OPUS and GIODIS, use only GPS signals. JUSTIN I believe uses all available constellation data.

Is this the results that we should expect to see, and is one processor preferred over another. I know the OPUS solutions are not processed by DPOS, but its very interesting that the reduced coordinates are similar in one axis or the other, depending on the processor.

I feel that GIODIS with the 8 CORS stations in the reduction, is probably the most diverse solution. The elevation of GIODIS seems to be the lowest, with Justin elevations being the Highest and OPUS elevations being somewhat in the Middle.

So if setting control and using static files, which processor would yield the best real world coordinate, or are there too many variables to account for?

These are all 24 hour files collected at a 30 second epochs.

What did you end up settling on? I anticipate being in this same predicament soon…

 

[James Suttles]

I am basically using the average of all three. I have found that its really close to the opus solution, like 0.05', considering that other surveyors following behind me will most likely be using equipment that is not capable of DPOS, and they will rely on RTN or OPUS, I felt that using the average would give me a certain level of confidence, I will be providing the next guy that retraces my work something that is within an acceptable distance from what they will be obtaining with their current means of reduction.

My hope is that once OPUS starts using the other constellations, that the results will be closer than what is currently presented between the 3 different processors. I think Giodis is probably the most accurate, because the number of CORS used, is superior with 8 for Giodis vs the 3 that OPUS utilizes. Only thing with Giodis is it only processes GPS, just like OPUS. Justin has all the constellations, so its hard to compare apples to apples.

I have discussed with other JAVAD users, and they feel I should use the Justin coordinate, as OPUS will have to eventually incorporate the other constellations, and when that is implemented, it should process closer to Justin. So the theory is that if we already have the constellations included with Justin, future retracement by using other equipment should match us, when OPUS catches up to Justin's processing.

So no real good answer. Using the average that I have between the 3 processors, yields 0.05' difference horizontally and about 0.01' vertically from the RTN and OPUS. I am currently using the average of 60 days, which is not changing any longer, and if it does it is in the thousandth's. To just recap, I feel that 0.05' is within my certification and should be close enough to be within the normal error that others will see.

Where I run into a possible mix and match, is if I have a project that is too far from my stationary base, and I have to used our LS+ base, then I end up starting with an RTN derived coordinate, that has to be sent to DPOS, and OPUS, and then average those, take the average and translate it to be consistent, with our stationary base.

Arguments can be made for holding just OPUS/RTN and then the argument can be that the average is the one to hold.

This Just how we are doing things, if there is a better way, I am very interested knowing what else to try.

If you would like my spreadsheet to use for your base point average, let me know, I am glad to share.

 

[Bryan Enfinger]

Guidelines for Establishing and Operating CORS - National Geodetic Survey

geodesy.noaa.gov

I'd use this, as the result will match the surrounding CORS network.