NGS GVX Vector Exchange File Format

Kelly Bellis

ME PLS 2099
5PLS

Watching this webinar today, I had to stop it and come see if Javad had posted anything on GVX and was happy to see that Jim did :)

In this webinar from last year, Dan Gillins mentions that NGS has reached out to Javad and other OEMs for their input in regards to NGS developing the GNSS Vector Exchange format, while noting that this GVX page (as well as this thread) hasn't been updated for quite some time.
 

Jim Frame

Well-Known Member
A year later, checking to see if any progress has been made on a GVX exporter/converter. I could use one for a current project.

Edit: I just saw another thread that shows a GVX export option. I'll check it out!
 

Jim Frame

Well-Known Member
I successfully exported a GVX file from my LS project. However, when I uploaded the GVX to OPUS Projects 5.0 beta, I got an error message saying that the reference system specified isn't supported by OPUS Projects.

The reference system number in the GVX file is 216, which is the WGS84(G1674) Coordinate Reference System per the ISO Geodetic Registry. The NGS GVX Reference document allows only a limited number of reference systems, all of which are ISO Geodetic Datums rather than Coordinate Reference Systems. Among the NGS-accepted datums is ISO 196, which is WGS84(1674). When I changed all references in the GVX file from the 216 designator to 196, OPUS Projects seemed to accept the file without issue.

I'm having trouble right now getting OPUS to recognize my OPUS Projects identifier, so I can't yet see if the RTK vectors have gotten properly registered in OPUS Projects. However, it would be nice if the GVX export function either changes the stored reference system number to 196, or allows the user to select among various reference systems.
 

Jim Frame

Well-Known Member
I was able to get OPUS Projects v5.0 beta to accept my static files (I was using the production server instead of the beta server), but I'm not yet able to get it to load RTK vectors from the GVX file exported from my T-LS. It acknowledges the number of vectors in the file prior to uploading -- the upload web page shows the number of vectors in the file -- but after upload no RTK vectors appear.

One thing that I think needs attention: the MASK element (a subelement of the QUALITY_CONTROL element) appears to be improperly formatted. Right now it comes out as <MASK /> when I think it should be <MASK></MASK>, or maybe it has to contain values for the <MASK> subelements. (I'm conversant in XML, but it seems that the general pattern requires tags to be closed.)

Pictured below is an excerpt from the GVX I exported:

t.jpg


Fixing the <MASK> tags didn't cure my problem, though -- OPUS Projects still doesn't show any vectors after I upload the GVX file. :(
 

Jim Frame

Well-Known Member
Here's the response I received from Dan Gillins, the architect of GVX:

Hi Jim, thanks for Beta testing your files in Beta OPUS-Projects 5.0. I took a look, and there are 3 known issues with GVX files from JAVAD. Unfortunately, these 3 issues are preventing your file from uploading. I at least fixed your GVX file to the point that it will upload into the software. That way, you can at least continue Beta testing. Please see attached and let me know if you notice any other issues. I've also notified JAVAD of these items listed below.

1) The GVX file does not provide PDOP values for the vectors. Unfortunately, BETA OPUS-Projects 5.0 expects PDOP values, and it will fail to upload the file without them. We have fixed this issue in OPUS-Projects 5.1 (which ignores PDOP when it is not included) which will be released to our BETA server soon. In the meantime, I simply manually renamed all of the TDOP fields to PDOP so that your file will at least upload; however, please note that the "PDOP" shown on the screen is actually TDOP. It's just metadata and won't affect any adjustments or results.

2) The coordinates for your points are shown to be in WGS 84 at epoch 2022.5. This is unusual, but maybe that is correct? Please check the coordinates for your base stations (especially at GRAR which shows as keyed-in coordinates). Your coordinates should be in the same reference frame and epoch as the coordinates for your bases. I'm used to them being in NAD 83(2011) at epoch 2010.00. I manually changed the REFERENCE_SYSTEM and EPOCH to be NAD 83(2011) Epoch 2010.00. That might be a faulty assumption on my part, but it allows the file to upload successfully.

3) The major issue is that for some reason, GVX files from JAVAD have faulty correlations in the Y-Z component for the GNSS_VECTORs. Unfortunately, these PYZ values are frequently outside of the limits of [-1, 1]. This causes OPUS-Projects to ultimately attempt to take the square root of a negative number, and the software fails. I believe the JAVAD GVX exporter must have a bug in it when it exports the PYZ values. To allow you to at least upload the file, I changed all PYZ values outside of [-1, 1] to be zero. This is not technically correct, and JAVAD needs to fix this. Our future version of OPUS-Projects (version 5.1) will prevent users from uploading files with correlations outside of [-1, 1], and it will warn the user.
 

Andrey Zhiganov

Active Member
JAVAD GNSS
Jim, could you please send the project to the support so that we can investigate the export to gvx of the real project.
 

Jim Frame

Well-Known Member
Another request: in the GVX <POINT> records, I think it's fine to use the point number for the <ID> element. However, the user ought to be able to choose the code or description for the <NAME> element. For example, the project I'm working on involves multiple shots on each point for redundancy (often over several days). OPUS Projects uses the <NAME> element to identify the point, so the way the exporter is currently configured OPUS Projects won't see any redundancy, since each point has both a unique <ID> and a unique <NAME> -- they look like different points. I'm using the station name as the description, so if the exporter placed the description in the <NAME> element I wouldn't have to edit the file to change the <NAME> from the point number to the station name.

Here's a <POINT> element as the exporter created it:

<POINT> <ID>19</ID> <NAME>19</NAME> <EQUIPMENT_ID>GVX_Equipment_Javad</EQUIPMENT_ID> <ARP_HEIGHT>2.025</ARP_HEIGHT> <POINT_TYPE>PPP Solution</POINT_TYPE> <COORDINATES> <REFERENCE_SYSTEM_ID>126</REFERENCE_SYSTEM_ID> <EPOCH>2010</EPOCH> <GEODETIC_COORDINATES> <LATITUDE>39.0566210341</LATITUDE> <LONGITUDE>-122.0156864167</LONGITUDE> <ELLIPSOIDAL_HEIGHT>-15.2408</ELLIPSOIDAL_HEIGHT> </GEODETIC_COORDINATES> </COORDINATES> </POINT>

And here's what I'd like it to appear:

<POINT> <ID>19</ID> <NAME>FF25</NAME> <EQUIPMENT_ID>GVX_Equipment_Javad</EQUIPMENT_ID> <ARP_HEIGHT>2.025</ARP_HEIGHT> <POINT_TYPE>PPP Solution</POINT_TYPE> <COORDINATES> <REFERENCE_SYSTEM_ID>126</REFERENCE_SYSTEM_ID> <EPOCH>2010</EPOCH> <GEODETIC_COORDINATES> <LATITUDE>39.0566210341</LATITUDE> <LONGITUDE>-122.0156864167</LONGITUDE> <ELLIPSOIDAL_HEIGHT>-15.2408</ELLIPSOIDAL_HEIGHT> </GEODETIC_COORDINATES> </COORDINATES> </POINT>
 

Jim Frame

Well-Known Member
Has there been any further development of the GVX export since June of 2022, or did that project die along with Mr. Ashjaee?
 

Jim Frame

Well-Known Member
Is there anyone left at Javad who knows about the GVX converter status and its future? With the advent of OPUS-Project 5.0, GVX is too important for Javad to abandon. Fixing the problems with the converter seems like a pretty modest task, as the converter is most of the way there.

Anyone? Bueller?
 
Top