Activity Feed › Discussion Forums › GNSS & Geodesy › TBC & OPUS Extended Output Import ?
TBC & OPUS Extended Output Import ?
Posted by wildt2 on July 4, 2020 at 9:00 pmIf anyone here has written or found an import format for TBC to make use of the vectors within the OPUS extended output, I would greatly appreciate hearing from you. Thank you.
husker796 replied 3 years, 6 months ago 8 Members · 21 Replies- 21 Replies
Does drag and drop not work? Seems to work for everything else. Never used the extended solution but it works for xml.
I wrote a QB45 (BASIC) program many years ago to extract the G-File data (vector data) from the the OPUS Extended Output Report. The program generated a 3×3 covariance matrix for each vector, and wrote a Columbus input file (text). I used it quite a bit, but after OPUS_Projects came out, not so much. I still fire it up from time to time to compile multiple OPUS_Static observations on long term project control (RTK Base Stations). To be honest, I have found that averaging multiple OPUS_Static (6-10 hour) solutions, returns the same “answer” as Least Squaring them (+/- a mm or so).
Besides which, I believe that Columbus has had the capability of reading the OPUS Extended Output File (text) for quite some time now (although I have never tried it).
Loyal
@husker796, try dropping an OPUS email into TBC … 😉
I’m retired (more or less) and my programs won’t run on these new machines. Besides which, I don’t have ant idea what kind of file TBC would need. Hell, I can’t believe that TBC can’t just read the OPUS Extended report…(Oh wait, does the ‘T’ stand for Trimble 😆 )
I know that Trimble is/was working with NGS on the GVX format. As soon as the format is finalized, it should be available as an import into TBC. Until then, the XML is probably your best bet.
I am not sure this can be done. When I look at the import formats, and “store data as” in the drop-down, it wants it to be a point, level data, or surface. I don’t see a way to import vector components. So it does look like you could bring an OPUS solution in as a point, but not as vectors.
I do know that Trimble is in contact with NGS about the GVX format, but that might (probably?) be as an export format only, not as an import format. But of course I have no knowledge at all of what Trimble is planning, I am just basing that statement on past behavior.
@john-hamilton, I hoped you’d see this.
I see what you’re saying. Before they get around to completing the GVX, a workaround might be to create a translator to mimick the Trimble Data Exchange format which does include vectors maybe?
I don’t know what is truly gained by this, even if you could do it. The TBC baseline processor, using the same three CORS stations and Rapid orbits, gave me nearly identical results to OPUS on a five hour session conducted last Monday, June 29. There were small (mm level) differences in the XYZ vector components but the uncertainties were very close to the same and the coordinates are nearly identical – 1mm N, 7mm E, 11mm H. And the TBC engine is going to perform better in most cases on shorter sessions (under three hours). The Internet Download tool in TBC makes retrieving the data and processing it easy and painless – easier than doing an OPUS submission, IMHO.
I like to use OPUS Projects in parallel to TBC on networks – which are few and far between these days – as a check in most cases, but at times as the primary processor. But I rarely use OPUS for anything else, there’s just no reason to. I’ve processed thousands of baselines in TBC over the years, it’s easy to use and gives good, repeatable results.
I should add that the peak to peaks on the OPUS solution were 3mm, 12mm, and 18mm, so the TBC solution clearly fell within the uncertainties of the OPUS solution.
I agree, I would much prefer to process the data in TBC, especially for shorter duration occupations.
@lee-d, what can be gained from this? Well, for those that do not buy the baseline processing software, but do prefer having that vector ties to the CORS, this import would accomplish this for them, so that’s the gain or benefit. Personally, I have always processed my own vectors rather than relying on OPUS and I’ve also seen the acceptable comparisons you shared in your comment.
@john-hamilton, I’m with you John, but, still, TBC ought to be able to import the extended output. I have some RINEX files right now collected by others that TBC fails to process, even though OPUS has no issues with them and I can process the vectors using these RINEX files in other software. So, if I had the ability to import the OPUS vectors into TBC, I’d be able to include these points in my network even though TBC can’t process those vectors. In the decades I’ve been processing static baselines, this is a new one for me.
- Posted by: @wildt2
I have some RINEX files right now collected by others that TBC fails to process, even though OPUS has no issues with them and I can process the vectors using these RINEX files in other software.
This is interesting – in the past month we have seen the same issue, which is also a first for me, as I have never run into a static session that OPUS could process but TBC could not.
These were ~20 minute “rapid-static” sessions on the edge of what OPUS-RS could theoretically process (based upon the NGS reliability maps), so I was very surprised when OPUS-RS returned a solution and not a single baseline would fix in TBC. OPUS-RS results appear solid.
We did figure out that the problem files were all RINEX converted from native Leica format, but never found the solution. [Edit to add: I have processed many, many, Leica static sessions in TBC and never had a problem before.] Right now I am so buried in work that I can’t troubleshoot the problem, but it has to be related to TBC’s parsing of those RINEX files. Visually they look just fine…I will have to kick this up the chain on the Trimble community and see if anyone else is experiencing this.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman @rover83, ah well, it’s good to know I’m not alone, or, should I really say, I’m sorry you’re having my problem too 😉
The weird thing is I can process all these vectors including these RINEX files TBC can’t handle in the old Spectra GNSS Solutions software from 2012.
I’m confident they’ll get this figured out. I sent the data to Trimble yesterday.
The point of this post seeking an import for OPUS extended output would keep my project going for now.
Thanks for confirming this isn’t just me ! 🙂
@husker796, thanks. I’ll give it a try. Do you get the vectors to the CORS used in the OPUS solution?
Log in to reply.