OPUS-derived Positions Adjusted in Star*Net
> Your values were from a single static session, broken down into multiple fast static sessions. Each were well within acceptable error magnitudes. The worst was your last "day".
>* Begin Quote
[pre]1Day197d Delta-N 0.0166 0.0166 0.0224 0.7
1 Delta-E 0.0231 0.0231 0.0261 0.9
Delta-U 0.1675 0.1675 0.1985 0.8
>* End Quote
> Which I would have dismissed out of the batch and held the rest. Even though it was acceptable as shown by the standardized residuals.
Well the largest residual was in the Up component. As you can see from the standard error that was used in weighting the Up component (+/-0.1985 ft.), that residual was not unusually large. There was no reason to reject that OPUS-RS solution since the N and E components had much smaller uncertainties and were useful.
The large residual error in the Up component would have been a problem if one were just taking a average of several OPUS positions on a point instead of making a least squares estimate using weights for each position derived from the uncertainties (as one can do in Star*Net).
> How does the "decimeter" coordinate come into play? OPUS has estimated errors next to it's output to gauge the quality.
Well, in my view, the only real way to demonstrate the reliability of an OPUS solution is to have an independent check. If surveyors are using OPUS solutions from short occupations in suboptimal settings, I would tend to place a low estimate on the reliability of the results, which is what prompted my assessment that those results are more GIS-grade than survey-grade. The obvious best check on reliability is to just get two or more OPUS solutions on the same point. Another independent check would be to locate a station positioned via OPUS, by connection to another OPUS station with a GPS vector(s) of more than adequate quality.
If I include OPUS or OPUS-RS results in an adjustment, I do it by including the vectors rather than the positions.
> If I include OPUS or OPUS-RS results in an adjustment, I do it by including the vectors rather than the positions.
This method is a neat workaround for Star*Net, i.e. using the position with its uncertainty. The overhead is the generation of multiple points with different names (10Day231, 10Day215, etc.) surrounding the actual control point, but as long as those other points are named in a way that they can't be confused with the actual adjusted position of the point, it seems harmless.
I'm sorry, but how do I locate the original post that describes the process used ? I'm not able to follow the link provided by the OP.
does anyone know if the gfile produced by OPUS Projects is usable in Star*net
It's been awhile since I've done that, you *may* have to edit out the I (session models) records first. You may need to edit either the C record in the g-file, or the G1 record in the converted Star*Net file, to get your point identifiers right.
Note that character position in a g-file record is important, so when you edit a g-file you need to make sure you have the information in the right columns. I recommend having a copy of the NGS Annex N (Global Positioning System Data Transfer Format) document handy so you can decipher the g-file records properly.