OPUS and the Local Weather Pattern
On a recent project, I left my dual-frequency receiver logging observations on a convenient control point, CP1 on the map below, for over four hours on two days in order to get static OPUS solutions for the NAD83 (CORS96) Epoch 2002.0 position of the point. I only got 5hrs 31min worth on Day 178 as afternoon rains ended the field day early but had 7hrs 05min from Day 179.
A single OPUS-Static solution from more than 5 hrs of observations at a wide open site such as where I had the L1/L2 Microcentered Antenna+GP set up is ordinarily quite reliable if the solution statistics are good. By getting duplicate solutions on two days, there is a demonstration of solution quality in the repeatability and some redundancy to test the weights assigned to the two positions, one for each day, when they get adjusted in Star*Net with the rest of the GPS vectors connected to the control points positioned via OPUS.
The default solution for Day 179 looked just fine. It used the CORS sites TXSA (San Angelo), JCT1 (Junction), and TXLL (Llano) at distances varying between 75km and 121km. The solution was from more than 7hrs of observations, and the statistics looked good, so that was great.
On Day 178, however, there had been thunderstorm activity on the far horizon for much of the day and the initial solution that OPUS returned using the default CORS sites looked terrible. It wasn't survey quality and couldn't be used. The stations that had been selected were evidently in the weather pattern.
After examining other solutions using various other combinations of CORS sites, it looked as if they were also in the weather pattern. So I got bold and selected some more distant CORS sites, TXSN (Sanderson) and TXOE (Odessa) at 295km and 255km respectively. Those returned a solution with good statistics and with a position that was in essential agreement with that from Day 179.
In an ideal world, we'd have the map of the CORS sites superimposed on a weather map to see what the prospects were. In the real world, it's damn handy to have more than enough data for an OPUS solution.
Here's a plot showing the adjusted position of CP1, its 95% confidence error ellipse, and the horizontal and vertical residuals of the two different OPUS solutions from Day 178 and Day 179.
> In an ideal world, we'd have the map of the CORS sites superimposed on a weather map to see what the prospects were. In the real world, it's damn handy to have more than enough data for an OPUS solution.
Food for thought. Google Earth now has live weather maps. Check out: LIve weather maps in Google Earth
If you created a KMZ file for the CORS sites you use on a regular basis you could probably have exactly what you are looking for.
Peter Lazio
I've never used OPUS, so I don't know if it attempts to model out atmospheric disturbances, particularly ionospheric. If the local weather disturbances appeared to be on the horizon, was the observing masked raised above 15 degrees and recomputed? Can that be done with OPUS?
Using dual frequency receivers and the long observation times, most vendor software would allow the use of a Klobuchar model or even a more accurate computed model.
With more and more surveyors using OPUS, I think that it is important to understand how it attempts to deal with atmospheric disturbances, which are certainly not a new item in GPS observations.
> Food for thought. Google Earth now has live weather maps. Check out: LIve weather maps in Google Earth
>
> If you created a KMZ file for the CORS sites you use on a regular basis you could probably have exactly what you are looking for.
That's an interesting idea. For the work in the hinterlands, access to weather information, let alone the internet, is fairly limited, though. So the "weather template" really is needed after the fact, i.e. overlaying the weather pattern as it existed several days earlier on the CORS network to more efficiently diddle around with selecting stations for OPUS.
I'm thinking that something as basic as identifying stations with major thunderstorm activity reported during working hours would be a pretty good filter.
> I've never used OPUS, so I don't know if it attempts to model out atmospheric disturbances, particularly ionospheric. If the local weather disturbances appeared to be on the horizon, was the observing masked raised above 15 degrees and recomputed? Can that be done with OPUS?
My guess is that the key is identifying those stations that don't have thunderstorms hovering close in around or over them. I don't know what sort of QC checks are done on CORS data, i.e. whether the fact that a CORS site is used in an OPUS solution indicates that it has passed some minimum QC test or not.
> "In the real world, it's damn handy to have more than enough data for an OPUS solution."
i agree Kent, seems like the best results always happen six hours and longer; i shoot for 8 hour setups.
dla
> ...I don't know if it attempts to model out atmospheric disturbances, particularly ionospheric. If the local weather disturbances appeared to be on the horizon, was the observing masked raised above 15 degrees and recomputed? Can that be done with OPUS?
OPUS is an automatic, scripted operation. The standard 15 degree mask is used regardless of the situation. OPUS does piece wise modeling of the troposphere. I believe the increment is two hours meaning that the same tropospheric delay is used for two-hour increments. If the weather is changing very rapidly, as may happen in the summer, the solution may be biased.
Peter Lazio
> ...For the work in the hinterlands, access to weather information, let alone the internet, is fairly limited, though. So the "weather template" really is needed after the fact, ...
The video in the link I provided did say that one could download the weather for the past 6 to 12 hours so that does provide some after the fact analysis but perhaps that does not provide enough buffer for later analysis.
Peter Lazio
> OPUS is an automatic, scripted operation. The standard 15 degree mask is used regardless of the situation. OPUS does piece wise modeling of the troposphere. I believe the increment is two hours meaning that the same tropospheric delay is used for two-hour increments. If the weather is changing very rapidly, as may happen in the summer, the solution may be biased.
It would be interesting to investigate which changes in weather at a CORS site are the most problematic.
