Community Forums

Share:

OPUS-derived Positions Adjusted in Star*Net  

Page 6 / 6

Kent McMillan
Posts: 11490
Member
(@kent-mcmillan)
10,000+ posts
Joined: 9 years ago

> 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
Length 0.1699>[/pre]
>* 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.

Reply
John Hamilton
Posts: 2647
Member
(@john-hamilton)
2,500+ posts
Joined: 9 years ago

If I include OPUS or OPUS-RS results in an adjustment, I do it by including the vectors rather than the positions.

Reply
4 Replies
DANEMINCE@YAHOO.COM
(@danemince@yahoocom)
Joined: 9 years ago

250+ posts
Posts: 382

@john-hamilton

does anyone know if the gfile produced by OPUS Projects is usable in Star*net

Reply
John Hamilton
Member
(@john-hamilton)
Joined: 9 years ago

2,500+ posts
Posts: 2647

@danemince@yahoocom

I write my own translators for star*net (total station, leveling, and GPS), so I am not sure if one can directly use the g-file but certainly the information in there can be used when reformatted if not directly usable by import. 

Reply
GeeOddMike
Member
(@geeoddmike)
Joined: 9 years ago

500+ posts
Posts: 985

@john-hamilton

For those unaware of the NGS GPS Data Transfer format aka “GFILE” Here is a vector record from an OPUS-extended solution and the relevant portions of Annex N:  https://www.ngs.noaa.gov/FGCS/BlueBook/pdf/Annex_N.pdf

0AB18FD0 FDB3 4BAD 8F55 645FBFCF2D3B
9FDB44FC F0BF 41A4 9727 4AD1CC1A8167

Reply
John Hamilton
Member
(@john-hamilton)
Joined: 9 years ago

2,500+ posts
Posts: 2647

@geeoddmike

Because I do a lot of bluebook projects (and don't use OPUS projects), I wrote software to create B and G files from trimble data (B file) and TBC processing (g file). One thing to note if anyone is trying to read or write to a g file format (and the b file as well) is that everything is extremely column sensitive, and there are no decimal points. To write vector components to the g file you need to multiply by 10000 and treat it like an integer, and to write correlation terms you need to multiply by 1000000 and also treat it like an integer (i.e. no decimal)  

Reply
Kent McMillan
Posts: 11490
Member
(@kent-mcmillan)
10,000+ posts
Joined: 9 years ago

> 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.

Reply
Manzanita
Posts: 5
Member
(@manzanita)
5+ posts
Joined: 2 years ago

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.

 

Thanks

Reply
2 Replies
Norman Oklahoma
Member
(@norman-oklahoma)
Joined: 4 years ago

2,500+ posts
Posts: 4537

Maybe this one?

Reply
Manzanita
Member
(@manzanita)
Joined: 2 years ago

5+ posts
Posts: 5

Much obliged

Reply
Jim Frame
Posts: 6054
Member
(@jim-frame)
5,000+ posts
Joined: 9 years ago
Posted by: @danemince@yahoocom

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. 

Reply
Page 6 / 6
Default
:)
:d
:wink:
:mrgreen:
:neutral:
:twisted:
:arrow:
:shock:
:???:
:cool:
:evil:
:oops:
:razz:
:roll:
:cry:
:eek:
:lol:
:mad:
:sad:
:!:
:?:
:idea:
:hmm:
:beg:
:whew:
:chuckle:
:silly:
:envy:
:shutmouth: