I have a large topographic survey that extends over 6km and the survey will be on grid. I am using Survnet for least squares adjustment but I have no Geoid in Survnet. I will be establishing control throughout the site with VRS RTK and traversing with total station which should be sufficient for project I am doing.
As I don't have a Geoid model in Survnet but do have in the VRS rover, will it make any major difference not having the Geoid in Survnet as my control will be spread from end to end with multiple control points set in between and no total station data will be more than 300-500m from a control point? My understanding is that it would make no major difference as the control elevations are being used.
I'm wondering why you do not have a geoid file in SurvNet? You are posting on a web forum, so you have internet access. Carlson should download that for you automatically.
That said, if you are not processing your GPS in SurvNet, just your total station data, I don't see why the lack of a geoid model would have a major impact on your final elevations. Your control coordinates will be in your final elevation datum, so your side shots will be calculated from those.
300-500 meters? Make sure you have the corrections for earth curvature turned on.
Does Survnet not allow for a geoid to be loaded? I would have thought Carlson software would have that capability.
If it's not possible, though, I would export out the grid positions plus geoid-derived ortho heights from the rover, then drop those points into Survnet, add your conventional observations and run the adjustment as a local coordinate system, fixing the VRS-derived values.
?ÿ
I'm wondering why you do not have a geoid file in SurvNet? You are posting on a web forum, so you have internet access. Carlson should download that for you automatically.
Carlson are unable to provide a working one for my area and I am unable to upload one in a different format.
?ÿ
?ÿlocal coordinate system, fixing the VRS-derived values.
?ÿ
I need it in Grid so I have the co-ordinate system customised. I normally don't fix the VRS positions just give them a realistic standard error.
Maybe Survnet works differently than other LS programs I'm used to, but generally speaking if I import VRS-derived grid values plus conventional observations into a "local" coordinate system and run an adjustment fixing those values (with or without standard errors), the adjusted positions of the conventional observations will be in grid even if the coordinate system is technically "local". That keeps the software from trying to reduce everything to the ellipsoid (because you don't have a geoid).
Of course, depending on the combined scale factor of your project area, you may wish to apply a scale factor to your total station observations...
The standard practice for GPS control surveys is static observations connecting the control points locally as well as to broadcasting network stations. All the control is adjusted as Lat, Long, Height.
No grid or geoid numbers are projected until the Lat, Long, Height values are fixed. Grid numbers are a function of the Geodetic values. Same with Geoid values. A Geoid value shouldn't be adjusted, it's simply a number attached to a location not subject or relevant to the adjustment.
I'm making an assumption that this is a 6km corridor survey for topo that will be used for design and eventually construction. If so I would suggest a level run for the 6km through the control points, normally we will choose control points that are inter-visible, off the proposed construction if possible, set nice as stable monuments, then do the surveys. Levels through 6km don't take that long unless you are dealing with large grade changes and then it may be more cost effective to use trig levels for elevation control and checks.?ÿ
Frankly I'm not sure how a rover connected to a VRS will produce much of a valid adjustment, I can see how multiple locations and comparing the given accuracy numbers might do something but it's the local vectors between points that firm up a control GPS survey. Redundancy at each point is paramount.?ÿ
But if this is for a roadway, then squeezing out that last cm horizontally shouldn't mess it up. I'd be most concerned with elevations. I would want to know the Geoid model is working well with some kind of level checks, whether trig levels or conventional levels.
The standard practice for GPS control surveys is static observations connecting the control points locally as well as to broadcasting network stations. All the control is adjusted as Lat, Long, Height.
Star*Net adjusts on the grid, then calculates LLH.?ÿ That's the reason Star*Net projects are limited to a few hundred km in extent.
For 34 years I have been using Geolab to adjust my networks. Last year I started using star*Net to adjust combined GNSS/conventional deformation surveys at the insistence of my client (now no longer there). There are some things I like about Star*Net over Geolab, and vice versa. Geolab does the adjustment in ECEF XYZ, so it does not have the limitation in area that Jim mentions.?ÿ
I recently had a small 10 point GNSS network in Texas that I observed (VRS) and adjusted using Star*Net. However, I neglected to change the UTM zone from a previous project, so it did the adjustment in zone 18 (east coast) rather than zone 15 that it should have been. All the stats looked great. However, when I viewed the points in google earth, they were about 4 m shifted. Now, I know that GE is not perfectly rectified, but 4 m in an urban area seemed like way too much. Turns out that Star*Net will give no warning at all in a situation like that. Once I looked at the CORS coordinate being used (which was constrained as a PH coordinate), I could see that it didn't match what was input. I always use lat/long rather than UTM or state plane. Not sure exactly what it did, but it took the constrained lat/long I entered, converted it to UTM18, did the adjustment, and then converted it back to lat/long, and that value was shifted several meters.?ÿ
There are certainly ways to screw up a Star*Net adjustment without seeing any red flags.?ÿ My favorite is to enter one or more ellipsoid height constraints in meters and forget to switch back to feet.
