Notifications
Clear all

SurvCE - Grid to Ground

6 Posts
3 Users
0 Reactions
1 Views
(@byanez)
Posts: 29
Registered
Topic starter
 

Greetings,

I have SurvCE, v. 3.???, which I am trying to learn how to use for RTK. The main problem I have is figuring out how to do a grid-to-ground correction.

I have coordinates on a group of points measured with total station. I then stored coordinates on those same points using RTK, with autonomous state plane coordinates at the base location.

THEN, I set the grid-to-ground combined factor in the Equipment/Localization/GPS tab, using the state plane coordinates of one of the points I shot, and setting geodetic orientation.

THEN, I do a two-point localization using two of the points I shot, and arbitrary ground coordinates for one of the points.

SurvCE then asks if I want to reprocess raw data, and I say "sure". However, the coordinates of the points which I have already shot do not update in the points list. They are still state plane-ish large coordinates.

BUT, I notice that the "localization" HAS been made. I can stake out to my total station points and hit them fine.

SO, I guess this would work, but to have measured RTK coordinates on my points I would have to re-occupy them. That is not too practical as in most jobs I do not know how I will localize until I have measured to several monuments.

Is there something I am missing that would get the coordinates of points I have already shot to be re-calculated on the localization?

Thanks.

 
Posted : 28/11/2016 7:54 am
(@mark-silver)
Posts: 713
Registered
 

When you reprocess the raw file, only points that have 'raw' data will actually be re-processed. So if the points where hand-entered points they will not be recalculated. One could do this with the translation tool [ Video ]

I made a video on this last year based on the presentation I did at the Carlson conference: [ Mark's G2G Video ]. It is not horrible.

While we are at it, make sure you have a valid GEOID file loaded (EQUIP: Localization: GPS: Geoid...) so SurvCE can reduce your orthometric heights to ellipsoid when it generates the combined scaled factor.

 
Posted : 28/11/2016 8:02 am
(@byanez)
Posts: 29
Registered
Topic starter
 

Thanks, Mark. I used your videos to learn how to do grid-to-ground, and they are very good!

I measured to the points with GPS, so they should have raw data associated with them, or is there a setting that I have to use to make sure raw data is stored?

 
Posted : 28/11/2016 8:21 am
(@mark-silver)
Posts: 713
Registered
 

Hard to say, shoot your fileset to me by email and I will smoke it out. Let me know which points you are interested in.

In the old days, I would have just had you send me the .rw5 file, but I may want to look at the .loc file too. I will send you a DM with my email address in a moment.

 
Posted : 28/11/2016 8:30 am
(@nw-staker)
Posts: 71
Registered
 

Using a two point localization all the steps you have done are correct your are missing one thing though.

You need to go to File>Raw Data>editprocess GPS.

Just like in the localization screen it will pull up a screen with a scale factor. Make sure it the scale factor you read in the TS screen. Sometimes it holds the last jobs scale or holds 1.

After processing it will ask you if you want to update and save the CRD. This will update all your coordinates to your local coordinates.

I think I have a step by step write up somewhere I did for my guys. Feel free to pm with any questions on localization. I deal with in a daily basis and have probably encountered about every issue possible with this process. My guys don't seem to understand grid to ground.

Also once all processed you can go inverse points you've shot and you will see two distances ground and grid. if you don't think it is still working and unsure if you are on grid or ground setup your gun and measure between two innervisable points atleast a half mile or more is my recommendation.

Also before even storing a single point I will go in and read my grid/ground and have that on before I even start.

 
Posted : 03/12/2016 7:00 am
(@mark-silver)
Posts: 713
Registered
 

Whoops, [USER=520]@byanez[/USER] and I exchanged email earlier and I did not follow up with the conclusion here.

The conclusion may actually be of value to others so I will post an abbreviated solution here. I don't know if Byanez wants his data files strewn around the internet so I have purposely obfuscated some of the details, I am sure the big picture will survive:
[INDENT]It looks like you shot several of the points (1,2,3) more than once, then instructed SurvCE to do a GPS average on the multiple observations of each point. The GPS average overrides the reprocessed points. Thus points 1, 2 and 3 appear to not reprocess (in reality they do, but are overwritten by the averaged SP entry.)

For example:
[INDENT]GPS,PN1,LAxxx,EL1017.313066,--MAG
--GS,PN1,N xxx,EL3420.6261,--MAG
G0,2016/11/25 22:09:27,(Average) - Base ID read at rover: 0001
G1,BPBP004,PN1,DX-7.30561,DY-14.32856,DZ-23.53142
G2,VX0.00015295,VY0.00017713,VZ0.00021476
G3,XY0.00010786,XZ-0.00007321,YZ-0.00011786
GPS,PN1,LAxxx,EL1017.314808,--MAG
--GS,PN1,N xxxEL3420.6318,--MAG
G0,2016/11/25 22:10:37,(Average) - Base ID read at rover: 0001
G1,BPBP004,PN1,DX-7.30817,DY-14.33190,DZ-23.53437
G2,VX0.00012420,VY0.00018157,VZ0.00020579
G3,XY0.00010909,XZ-0.00007426,YZ-0.00012014
SP,PN1,N xxx,EL3420.62896,--MAG
--Averaged position from last two observations[/INDENT]
In this case PN1 is stored, then stored a second time, then averaged to form the SP,... entry. When you reprocess the .RW5 file the first entry is processed, then the second entry is processed and replaces the first result and then the third entry (the SP, record) is processed and is the final value for PN1.

It appears when you look at the point list that the reprocess did not work on these 'special averaged points'.

To fix this, I like to edit the .RW5 file rename the points with unique ids, get rid of the SP record and then reprocess. Here is my resulting .RW5 file:
[INDENT]GPS,PN1,LAxxx,EL1017.313066,--MAG
--GS,PN1,N xxx,EL3420.6261,--MAG
G0,2016/11/25 22:09:27,(Average) - Base ID read at rover: 0001
G1,BPBP004,PN1,DX-7.30561,DY-14.32856,DZ-23.53142
G2,VX0.00015295,VY0.00017713,VZ0.00021476
G3,XY0.00010786,XZ-0.00007321,YZ-0.00011786
GPS,PN1B,LAxxx,EL1017.314808,--MAG
--GS,PN1B,N xxxEL3420.6318,--MAG
G0,2016/11/25 22:10:37,(Average) - Base ID read at rover: 0001
G1,BPBP004,PN1,DX-7.30817,DY-14.33190,DZ-23.53437
G2,VX0.00012420,VY0.00018157,VZ0.00020579
G3,XY0.00010909,XZ-0.00007426,YZ-0.00012014[/INDENT]
Which when reprocessed generates this:

Which is more along the lines of what you expected.

(Readers Note: there was a third occupation of PN1 as PN1C in the file.)

This brings up a personal preference of mine: I don't like averaging the data in the field. I like to store a point (in this case it was a 30-second average), then store additional points with unique point ID's. I want to see the intermediate results, I can average them later (back at the office) if I want to. In this case, my strategy would most likely have been to store a 30-second average, then stake that point with a 30-second average, then do some more work and stake the point a 3rd time later in the day. All three points would appear in my .RW5 file as unique point ID's, and if the result of any of the staking averages was off by more than 0.02' I would commence with a total freak out.[/INDENT]
Sorry about the delay, It has been a crazy busy week.

M

 
Posted : 03/12/2016 8:13 am