I've been exporting GVX files from a TSC7, but I find that they need some editing in order to get them fully compliant with the GVX specification. NGS staff tells me that they haven't looked at Access exports, but that TBC exports work fine.
My version of TBC (5.52) is too old to export GVX. I'm wondering if one of you folks would be kind enough to import a small .job file (zipped with the associated .to2 files and attached herewith) into a current version of TBC and then post (or email to jhframe [at] dcn.org) a GVX export so I can do a line-by-line comparison to see what Access is leaving out.
Thanks!
Hi Jim,
Good timing! Saw your post as I was firing up TBC. Here's a GVX generated from TBC v2024.00.
(I grabbed everything with Ctrl+A during export - from what I have seen in very limited testing, TBC only exports the required items. If something looks goofy let me know.)
That was quick! I'm looking through it now, will report back on what I find.
Thanks!
The differences are mostly what I expected -- notably, the Access export uses <REFERENCE_FRAME> instead of <REFERENCE_SYSTEM> throughout, and adds a cryptic prefix to the reference system ID, both of which cause OPUS Projects to reject the file.
I was surprised to see that the TBC export doesn't include PRS antenna information beyond the GPPNULLANTENNA designation. I was told that the actual PRS antenna model needed to be in the GVX for OPUS-P to correctly process the vectors, but maybe that's not the case. I don't recall if the antenna issue was causing rejection of the files.
My understanding of the null antenna concept is that the antenna model offsets are built into the vector data so that the hardware needn't be identified. But I'm putting the PRS antenna and receiver info into the GVX files anyway, since I already have that hard-coded into the application I wrote to modify the files and OPUS Projects seems to like them once edited.
At this point it's unclear to me exactly how OPUS Projects handles the GVX vectors. I'm hoping that it takes the adjusted positions of the PRSes, does a separate adjustment of the redundant NRTK vectors based on their error estimates, and then propagates the adjusted NRTK vectors from the adjusted PRS positions.
I have several stations in my project that have vectors from two different PRS bases, and one PRS shows a 5 cm difference in ellipsoid height between the PRS position shown in the GVX and the OPUS-S solution for that PRS. The others all agree within a couple of mm. I don't want that offset to show up as excessive error in my project.
I've asked NGS staff for clarification, but haven't heard back yet.
These will import into NGS:
Rover83 probably just "used the data collector coordinate system" upon import, which is what I did at first, so it plopped into the correct spot. But that coordinate system has a slightly different definition than if you select the correct parameters with coordinate system manager. (I think it doesn't use/define the reference ellipsoid exactly correct so that NGS will like it.)
But the base location(s) don't seem to plot near any public CORS that I could find...? (I'm not current on all things CA.)
The bases are part of a private VRS -- they're not NCN CORS, so they're likely not familiar to anyone who doesn't use that network.
(I think it doesn’t use/define the reference ellipsoid exactly correct so that NGS will like it.)
Yeah, it's a naming issue, and one of the minor bugs that I was hoping would get fixed at some point.
Testing with Access & TBC 2024.00 confirms it's still an issue.
Access rectified/cleaned up the SPCS naming issues a few versions ago, but TBC still does not automatically recognize GRS80 ellipsoid parameters, so it still says "Ellipsoid from Data Collector"...
I see that CA has quite the spaghetti of "CORS Networks", and various epoch(s), etc. with all the movment out there. I wouldn't want to try and keep track of that nightmare.
I post-processed your data against two (2) NCN CORS. The reference position of the private CORS to the NCN (NAD83 2011; 2010) is about 4cm horizontal and about 6cm vertical. Not sure what it's supposed to be referenced to, but NGS is all about NSRS.
I've only ever used OPUS Projects with NCN and/or with physical rtk obs from passive NGS monuments through OPUS into O-P while also importing GVX.
I'm not sure it will work unless you use NCN/OPUS; that's kinda the point.
Private CORS have a lot of variables that users/NGS can't control.
You would probably have to download the raw gnss obs data for each private cors and run it into OPUS, and then it might work "normally".
'You would probably have to download the raw gnss obs data for each private cors and run it into OPUS, and then it might work “normally”.'
That's the workflow I'm using.
> — notably, the Access export uses <REFERENCE_FRAME> instead of <REFERENCE_SYSTEM> throughout, and adds a cryptic prefix to the reference system ID, both of which cause OPUS Projects to reject the file.
Jim,
You can edit the XSL style sheet that Access uses for the export.
Should be pretty straight forward to change that text, and to delete the prefix
"You can edit the XSL style sheet that Access uses for the export."
Good to know, but too late for this project. I finished the field work yesterday, and turned in the rented TSC7 this morning. The converter I wrote made the editing a one-command task anyway, so once I sussed out the needed changes the revisions were quick and easy. (I created a separate project for each field day, so each day got its own GVX. I found out the hard way that OPUS-P doesn't like big GVX uploads.)
