LS Vector Data in Star-Net

T.Guisewhite

Active Member
Just realized another thing about this Star*Net process.

Above I mentioned that you need to change the file extension from .gfile to .ngs in order for Star*Net to recognize the vector file.

This can be done in the LS by editing the extension prior to exporting.
Cool thing is...it remembers the .ngs extension so you only have to do it once.

Nice little shortcut there!

You can do the same with the C Record file I described in post #10. Change the extension from .txt to .dat in the LS and it remembers it for next time.

Pretty Cool...
 

Jim Frame

Well-Known Member
I almost always edit the g-file to change the point numbers on repeat observations, so I keep the original .gfile for archival purposes, save it as a .ngs file, and edit the latter. (I do something similar with total station raw data files, saving the .rw5 as .rwb and editing the .rwb to fix things like HR and description goofs.)
 

T.Guisewhite

Active Member
9011


Hats off gentlemen...
I really appreciate the ability to contribute user feedback and know someone is listening!

I just updated to JField 3.0.2.1151 and StarNet GPS vectors is now included in the export options...

And...it works beautifully
No more need to fiddle with our CFile work around (although I must say...I was really stoked on it)

The .gps file gets exported from the LS and simply added with the + box to the StarNet project...all the From - To stations look great...AND ALL THE POINT DESCRIPTIONS ARE THERE.

Well done!!

One small thing I had to correct:
The base coordinate came in as a C record which is for Northing / Easting in StarNet... but the base coordinate was output as Lat/Long format...which I believe should be a P or PH record.

I would vote to keep the C record line but replace the Lat/Long with North/East/ Elev. if that is a simple fix??

Again...really nice upgrade here!!!! Now I can’t wait to play with the RW5 and SurvNet.
 

T.Guisewhite

Active Member
One more update on the exact format Star*Net accepts here.
I've attached a recent project and it's output files for you to see what is going on with this.

Currently J-Field's StarNet Vector Output sends out a second line in the file that looks like this:
C 9001 35.200011 -81.070182 177.658507 0.00347173 0.00355785 0.00350412 'BASE

This is the base position that it's sending over with the vectors...but the format needs tweaked just a little.

There are a few options that would be nice to see in the StarNet Vector output options screen.

First would be to have the option to:
[ X ] output base position as Starnet Lat/Long "P" Record Line
Below that option we would probably need to also have:
[ X ] output longitude as positive value (default to be Negative Longitude)
[ X ] output base vertical as orthometric height (default to be Ellipsoid Height)
Units: [ ] Meters [ X ] US Feet [ ] Int Feet

(these would be StarNet preference options...so this way guys could set it up to have it spit out a file for their typical work flow and avoid some editing)
(I don't know how to tell StarNet that just this one line would be an Ellipsoid Height...or that it is in Meters...So these options would bypass a little extra work for that)

A correct StarNet Format P record line In Lat / Long / Elevation for the attached project with these options checked would output like this:
(Point) (Lat) (Long) (Ortho) (StdErrLat) (StdErrLong) (StdErrZ) (Desc)
P 9001 35.120001435 81.041263168 688.699 0.00347173 0.00355785 0.00350412 'BASE

The second option that would be nice is if we could choose:
[ X ] output base position as StarNet Coordinate "C" Record Line
(with this option checked, it would grey out the "P" Record options)
(this option would just output a Northing Easting Elevation line in the current project projection)

A correct StarNet Format C record for the attached project with this option checked would output like this:
(Point) (N) (E) (Elev) (StdErrN)(StdErrE)(StdErrZ) (Desc)
C 9001 534166.291 1381615.631 688.699 !!! 'BASE
(in this example I have !!! in place of the standard errors for StarNet to know this is a fixed position)

Ideally if you can output both of these formats P or C records...the only editing to the file in StarNet would be the !!! which is always necessary relating to fixed control for the specific project.

The benefit of the P line over the C line would be that working your adjustments from geodetic positions can eliminate bad coordinate systems coming in from the field. Any bad setup of the project in the LS would be caught and corrected when processed through your pre-defined templates in StarNet...It's a good quality control step of post-processing GNSS data.

Attached file extensions were changed from .gps to .txt so they could be attached

Thanks!
 

Attachments

  • 463 Lake Wylie-190730 06_03_20.zip
    13 MB · Views: 335
  • Current Output Format.txt
    1.8 KB · Views: 290
  • Proposed Output Format.txt
    1.8 KB · Views: 300

Andrey Zhiganov

Active Member
JAVAD GNSS
Timothy, thank you. I will add it.

...
[ X ] output longitude as positive value (default to be Negative Longitude)
[ X ] output base vertical as orthometric height (default to be Ellipsoid Height)
Units: [ ] Meters [ X ] US Feet [ ] Int Feet

Are these options for 'P' case only?
 
Last edited:

T.Guisewhite

Active Member
Timothy, thank you. I will add it.

...
[ X ] output longitude as positive value (default to be Negative Longitude)
[ X ] output base vertical as orthometric height (default to be Ellipsoid Height)
Units: [ ] Meters [ X ] US Feet [ ] Int Feet

Are these options for 'P' case only?
Yes...those are for the “P” line

So a default P line would be:
P (Point Name) (Lat) (Negative West Long) (Ellipsoid Ht) (StdErr Lat) ( StdErr Long) (StdErr Ht in Meters) (‘Description)

An optional P line would be:
P (Point Name) (Lat) (Positive West Long) (Orthometric Ht in feet or ifeet) (StdErr Lat) ( StdErr Long) (StdErr Ht) (‘Description)

A correct C line would be:
C (Point Name) (Northing) (Easting) (Orthometric Ht) (StdErr N) ( StdErr E) (StdErr Elev) (‘Description)
 

T.Guisewhite

Active Member
I’m noticing that cluster averaged points are coming through in the StarNet Vector output as separate vectors...that’s a no no!

...they are not vector observations...they are computed.

Only observations should be making it out via this export.

I have an ALTA Survey I’m working on... I processed it in StarNet and output a list of points that did not meet ALTA requirements. I went back to check the few outliers and to give them another vector or two.

After processing today’s data into the project I can see there were more observations than I made. The bummer is it over estimated the accuracy of my points where the cluster averages snuck a vector in. Now I have to go back for like three more points. That don’t meet standards...grrr. Plus they have to be manually commented out in StarNet.

I know this might require some retooling of the cluster average command but I think that they should be “design points” after an average??
 

Shawn Billings

Shawn Billings
5PLS
I’m noticing that cluster averaged points are coming through in the StarNet Vector output as separate vectors...that’s a no no!

...they are not vector observations...they are computed.

Only observations should be making it out via this export.

I have an ALTA Survey I’m working on... I processed it in StarNet and output a list of points that did not meet ALTA requirements. I went back to check the few outliers and to give them another vector or two.

After processing today’s data into the project I can see there were more observations than I made. The bummer is it over estimated the accuracy of my points where the cluster averages snuck a vector in. Now I have to go back for like three more points. That don’t meet standards...grrr. Plus they have to be manually commented out in StarNet.

I know this might require some retooling of the cluster average command but I think that they should be “design points” after an average??

Negative Ghostrider.

This is exactly as it should work. The combined point is a surveyed point because it is based on survey data. J-Field has already done what you are doing in Star*Net (although differently), so you are correct that you should not include it in the Star*Net adjustment with the vectors that were used to create the average. Cluster average is supposed to create a survey point and export it as a vector just like any other point. My recommendation is that if you are creating cluster averages of survey points, export them to a separate page that you can disable for export, then you don't have to worry about them in Star*Net.
 

T.Guisewhite

Active Member
I was just thinking that after the post...

Keeping the cluster average in vector data makes it “smart” with coordinate system changes and such...that makes sense.

so I can specify the page with a cluster average output...then ignore that page in the StarNet output...I’ll try that.

I’m also assuming that previous cluster averages do not make it into a fresh cluster average? Say I did it yesterday then want to add more vectors...the first cluster averaged vector is ignored correct?
 

Adam

Well-Known Member
5PLS
I would only export the cluster averaged point and not the individual ones. J-Field already handled the details for you like Shawn said. Also, I always put averaged points on a page by themselves and just filter and delete all points before cluster averaging again.
 

Tyler

Member
Any idea how I can hold total station traverse data and compare the GPS vector measurements to it with out them holding any weight? I have run a traverse and closed it out flat. I would like to compare my GPS coordinates to these "true" points to assess the relative positional accuracy. Any thoughts on how to do this in starnet?
 

Jim Frame

Well-Known Member
Unless you have known coordinates on at least 2 of your points I can't think of a rigorous way of doing this, but for practical purposes you can simply put the C records in the .dat file and assign them large weights (like a foot) without importing the vector data at all. Star*Net will best-fit the RTK points to fit your traverse data and show you residuals.

Don't forget to assign realistic weights to your traverse data if you want meaningful results.
 

Tyler

Member
Unless you have known coordinates on at least 2 of your points I can't think of a rigorous way of doing this, but for practical purposes you can simply put the C records in the .dat file and assign them large weights (like a foot) without importing the vector data at all. Star*Net will best-fit the RTK points to fit your traverse data and show you residuals.

Don't forget to assign realistic weights to your traverse data if you want meaningful results.
Yeah, it seems like StarNet may not be the best tool for this but I figured it was worth a shot. I will see if I can get what you said to work. It is proving to be a difficult task to compare GPS coordinates to Total Station coordinates without processing them together unless there is something I am missing.

I have been using the Relative accuracy tool in the LS to see if multiple observations can meet the ALTA standards (2mm + 50 ppm). In this specific case two of my difficult measurements do not achieve these results. However, after combining the Total Station data in starnet they are able to pass these standards as I expected. The relative accuracy tool is neat way to create a report to show some kind of confidence in these redundant measurements.
 

Jim Frame

Well-Known Member
I tried this with a small (about 250' N-S) project I did recently:

t.jpg


I had 4-minute RTN observations on points 1 (just to the left of 4), 2 and 3. I weighted the RTN coordinates at 1.00' in all 3 dimensions. Here are the results:

t.jpg
 
Top