Grid/Ground are you happy with your software?

So far here is what I have examined…

One method shown in the Traverse PC video found here: Traverse PC Geodetics appears to be a rigorous application (at least for a map production software package). Average of grid scale factor at both ends of a line then Traverse PC appears to use the mean project ground elevation (user specified, and I read that as an orthometric height). A solution that appears to be tailored to PLSS cadastral survey methods.

Isn’t the technically correct method to use the average of the ellipsoid heights at the endpoints of each line (NAD83)? Perhaps the better alternative for engineering topographic surveys, control surveys, general positioning services for other design related professions and multidisciplinary projects?

Carlson Survey shows how to specify a scale factor based a given point in a survey (grid scale factor, elevation scale factor, or combined scale factor is not apparent to me) as shown in this video:

[flash width=560 height=315]//www.youtube.com/v/KZh_aOW5Xns?hl=en_US&version=3[/flash]

I think Carlson calculates/applies a project wide scale factor based on one point. Probably works great for smaller projects with little elevation change. However larger projects with more elevation change would have to live with significant distortion with this method.

I am pretty sure that C&G also applies a single project wide scale factor to bring distances to ground.

Is there a software package (map production specifically) available that labels/calculates the grid bearings/distances and that also has the capability to label a rigorously calculated line-by-line ground distance (an approach other than a project scale factor)?

> Isn’t the technically correct method to use the average of the ellipsoid heights at the endpoints of each line (NAD83)?

Star*Net lets (makes!) you decide how to do it:

That looks like transformation parameters. Is this a transformation done just to report ground distances?

Looks like StarNet also applies a user specified project scale factor.

I just use TBC and a simple way to do LDP's. It works great for me.

We are lucky to have several LDPs in the OVTS in Oregon. Standardized by administrative rules.

We also have a legacy Low distortion coordinate system that covers a 3 county area.

Obviously the whole topic can be avoided/simplified with LDPs.

I am just curious because situations arise where it can't be avoided. Also, based upon the number of times this topic comes up each year I thought a discussion of the methods employed by various software packages should be discussed.

Well, I'm not going to crank it out by hand. I suppose it depends on the data you have. I keep all my data in 3D (NEZ, LatLongHt, ECEF (pure)).

So if you wanted the factors from a SPC projection you'd just do a points report with the factors turned on and they'd be there for every point. You can also Inverse and request grid or ground as the output.

If you wanted to see grid type coordinates at a particular elevation (a LDP) you would simply change the projection to a LDP set for that elevation and list them out. If you have a lot of elevation change in the project you live with the distortion but its not as much as with SPC.

Here is a simple example. I have a Trimble TSC2. A project at 7000 feet elevation. I set up a simple LDP and a scale factor to make grid and ground the same at near 7000 feet.

Inversing in the TSC2 you can select grid, ground or ellipsoid distances.

Distance between my points 1 and 62:

Ellipsoid = 1967.581 feet
Grid = 1968.234 feet
Ground = 1968.237 feet

There is about 50 feet difference in elevation of the points.

If I changed the projection to a SPC the ellipsoid and ground distances would stay the same but the grid distance would change to the SPC grid.

OVTS should have read OCRS. I hate the autocomplete.

I'd be concerned about software computations after watching the video. Here's why.

In the demo of geodetic distances, the narrator tells us he's calculating a geodetic distance, a geodesic. His screen shows 5280 feet as that distance. Entering the coordinates for points 202 and 203 into NGS Inverse produces a distance of 5279.642 feet. A few seconds later, he hem-haws a bit and tells us that he's calculated a geodesic at elevation 1500 feet. Huh?

There's a column on his drawing screen with heading "Grid Factor." SPCS has a Scale Factor, an Elevation Factor, and a Combined Factor. There's nary a reference to a "Grid Factor." Since he was talking about a geodesic at 1500 feet, I thought it might be an elevation factor, so I divided 5279.642 by .99994232, the factor shown. That does not produce 5280 feet.

If what our guy has is a geodesic divided by an elevation factor, then he's computed a ground distance, and it will match very, very closely to the ground distance calculated by dividing the grid distance by a combined factor. Calling this a "geodesic at 1500 feet" disguises its true interpretation and adds to confusion.

Moments later, in his drawing view, the column labeled "Latitude" disappears and the latitudes of his points appear under the column headed "Longitude." Good Grief. Was this video made by Traverse PC or one of their competitors?

The best protection, I think, is to duplicate known calculations in any software before using it live. That will help isolate bugs and clearly define the terms.

Grid factor and scale factor are often used interchangeably in survey software.

Regarding geodesic at 1500 ft, I can see what he's saying. Applying a combined factor to a grid distance is still a scaled chord. Right? An expanded ellipsoid(for lack of a better term) would calculate the distance along the curve.

I haven't watched the video.

I think this is what they were aiming at...

http://www.cadastral.com/cad-datm.htm

In mountainous terrain (which I do not work in) using individual factors at segmented endpoints can cause problems. The distances aren't related to one another particularly if the average elevation varies substantially from other lines. It depends on your purposes and your reporting. For geometric closures it may be better to select a single combined factor even though this is less rigorous. If rigorous reporting is a priority then perhaps each line could be labeled with its proper ground distance and its own combined factor.

Yes, that and maybe a little more in his purpose. Traverse PC apparently can mix grid and geodetic coordinates in the same computation, and switch between grid and ground from two different perspectives. And that's good stuff.

I always like to be able to duplicate software calculations, either by hand or by using an alternate piece of software. As Shawn points out, the terminology in geodesy and surveying is not standard from user to user. Duplicating calculations firms up the meanings of the various terms in a particular piece of software in addition to verifying the math in the calculations.

The close agreement between a ground distance calculated using first SPCS and a combined factor and then a geodesic and an elevation factor is amazing. One is a chord and the other is a mildly S-shaped curve, but the calculated distances are virtually the same. One test of the software would be the closeness of these two values.

From my use of traverse pc they are not directly using a combined scale factor unless you put it in there yourself . It will give you the scale factor at the project elevation , which does me no good for State plane coords . When you do enter a combined scale factor it apparently applies it from 0,0 . Not what I like to do . They are set up for Oregon BLM procedures .

I have worked with a considerable number of software packages over the years. StarNet works hands down the best for purist Grid to Ground computations.
When it comes to setting up an LDP or hammering through a local project, TGO is tops. The computations are somewhat transparent. You can crash around the files that are modified at various steps in the project and see what it is doing. It is rare my hand calcs don't match perfectly.
From there we go Leica. Not overly robust, but it does the simple stuff very well.
I am currently living in Topcon Magnet exile. The software doesn't even compute a combined factor reliably. I especially love the 'un-documented feature' of really needing the inverse of the combined factor in the 'scale factor' box.
The only major brand lower in my book is Carlson. The software is complete fluff, incapable of even basic PP RTK. A dissection of raw data files reveals some truly scary stuff...

> I have worked with a considerable number of software packages over the years. StarNet works hands down the best for purist Grid to Ground computations.
> When it comes to setting up an LDP or hammering through a local project, TGO is tops. The computations are somewhat transparent. You can crash around the files that are modified at various steps in the project and see what it is doing. It is rare my hand calcs don't match perfectly.
> From there we go Leica. Not overly robust, but it does the simple stuff very well.
> I am currently living in Topcon Magnet exile. The software doesn't even compute a combined factor reliably. I especially love the 'un-documented feature' of really needing the inverse of the combined factor in the 'scale factor' box.
> The only major brand lower in my book is Carlson. The software is complete fluff, incapable of even basic PP RTK. A dissection of raw data files reveals some truly scary stuff...

Aren't raw data files, raw?

In most cases yes. With Carlson you get a geographic coordinate for each tie to a point. The 'process gps' button simply averages any multiple positions and projects or transforms the coordinates. If you made any errors gathering data you are limited to crude and simplistic solutions. ..

Are you referring to Carlson GNSS or Carlson Survey?