I've been asked to put up a post and request input from you, our customers, on the Grid To Ground function in Solutions.

I've already received some suggestions to have the ability to convert State Plane coordinates into Ground coordinates, while keeping the orientation of Grid North in the State Plane System. This way, the distances derived from Solutions Ground coordinates would still match with EDM distances, but the State Plane Grid North orientation would be kept.

Basically, we want to see how much interest there is for enhancements to the Grid to Ground conversion, and what these enhancements would be.

We welcome your input.

Best regards,

Richard Phelan

Thales Technical Support

Richard,

What you said.

It doesn't matter , to me, if the coordinates have 5 digits or 20 digits. The boundary survey needs tend to be ground distances and if oriented to grid North, all the better.

Simpler = better.

My 2¢,

Jimbo
Modified By James Webb on 12/4/2001 at 4:38 AM

About half of our projects need to be "modified" to ground before they are mapped. It would be a convenience if that could be done within Solutions. I think a system where the user could override a program selected grid factor would be best. That way control ties and other off project shots wouldn't necessarily affect the factor.

I must be in some bizarre alternate world or really missing something.

Ashtech Solutions already has the option to orient it's ground system to SP grid. All kinds of possibilities exist in both the "ground coordinate" and local coordinate feature.

The ground system definition has been discussed a few times here before. In my copy of what purports to be the same software there is a nice little radio button that is labelled under "Orientation" "To Grid North". In addition are the capabilities to rotate it any way you want or orient north to a specific point or lat long.

Why is it believed that the capability isn't there?

- jlw
Modified By jerry wahl on 12/4/2001 at 9:28 AM

Perfectly true Jerry.

I haven't used it yet but since Richard (Thales) was asking I figured and still do simple is better.

Actually it looks fairly simple after having read your post.

Jimbo

Well since no clarification on my reality check above, I would like to respond to the improvements issue.

I think the ground and local coordinate features in AS are pretty well implemented and the ground feature is particularly easy to use and understand. I haven't done extensive tests over a large area to evaluate any possible small anomolies that might exist in the ground system created, but interface wise it is pretty good and I would assume it all works as advertised.

The local feature existed in a slightly more crude fashion in Locus Processor and makes it possible to do a fit between an existing set of coordinates that you impose GPS control on, or if you have a known translation, rotation and scale from SPC. So technically it could do ground also, and there could conceivable be documented some methods on how to use it to do so.

The only problem or caveat I have with the ground feature which came up in a thread a few months ago, had more to do with the export function.

Users should be aware that when creating an export definition that the grid easting and grid nothing data elements DO NOT give you values in your ground system, and that there are specific data elements for ground easting and ground northing that should be used.

This means that coordinate exports for ground systems need to have their own export definitions. This is not a problem technically, however it seemed to me that it was a good thing to be aware of. Users being not keenly aware of the internal workings of the software, might not think of this and assume that grid values were for their defined ground grid system and create or use exports that had already been created for SPC, etc. The second danger is that you would thus get datasets that look like the ground system, but they are not (they are in the false northing and easting range of the ground system defined and so might not be noticed).

This is NOT a software issue, could be put into the docs, but most people don't scour the docs if they get the software to do what they want. A warning box could be dropped into the docs but ultimately it is just more of a user caution and awareness thing.

I have never examined the printed docs so not sure what they say, but a how-to step by step on an example could be developed or posted and linked to a FAQ if these issues come up often. The software and interface seems great to me as is!

- jlw

Richard,

Dun been thunk'n now.

While I doubt it would increase the accuracy on a project of a small area....

Why not apply the combined scale factor for each point ?? Instead of an average scale factor ?

With the processing power we are currently using, this probably wouldn't be that intensive an operation, wouldn't thunk s anyway. And would it not tend to provide better ground coordinates on a "larger" area job ?

Wondering.....

Jimbo

Thanks,

(1) At this time, when Solutions creates a new Ground System, and "Grid North" is chosen, this is a Grid North orientation in a Local Projection, not Grid North orientation in a particular State Plane projection zone. At the origin of this Local Projection, the azimuths will really be Geodetic azimuths. This type of setup works fine if there is no need to maintain the State Plane Grid orientation, but in other cases the State Plane Grid orientation needs to be preserved.

(2) For most surveys, I think that using the average Combined Scale Factor (CSF) in Solutions gives a reasonable agreement Vs EDM.


I'm thinking that around 15,000 feet line length and around 200 feet elevation difference are pretty commonplace for EDM measurements ... do you agree? What are the longest EDM distances and largest height differences that you work with?


If there is a large enough elevation difference between the 2 stations, and the lines are long enough, I would agree that a CSF using the Elevation Scale Factor of only the EDM base station and the average Line Scale Factors of the 2 stations would improve the Solutions Ground distance agreement Vs EDM Ground distance somewhat. Solutions would have to be told which station the EDM was set up on.

I'd have to look into this further and make sure the State Plane orientation isn't affected too much by scaling the individual distances in that way........this could potentially cause a problem.


(3) I agree that the Ground export issue mentioned above is somewhat misleading. This has been noted and entered into our database. Maybe having a warning in the software or having certain export options greyed out when a Ground System is active would make this less of an issue.

4) Solutions can force a Local Grid Scale Factor of 1.000000 by assigning a scale factor of 1.000000 in the Local Grid Transformation. But, in Local Grid Systems the Grid distances may not agree with EDM distances, especially if there are large height differences in the survey area.

For Grid to Ground conversions, the CSF has to be calculated from the Line Scale Factor (LSF) for the Map Projection and the Elevation Scale Factor (ESF) for the points. Otherwise, if there are significant height changes, the Grid distances won't be reduced properly to Ground. The LSF is set to standardized values for State Plane Coordinate Zones and can't be changed.


BR, Richard

Re: your #4, if you did a transformation between your GPS networks SPC's and a set of local ground coordinates you would get a scale factor different than 1 that would be very close to combined factor. If you 'force" it to 1 you would of course move it back to ellipsoid.

Re: #3, greyed out is good solution, may be hard to implement though.

Re: #2, not my issue however there is nothing you can do in a projection to deal with variation of elevation. Nothing.

A projection can be optimized to minimize the effect by having the projection surface approximate the ground surface, but if you have varying elevation you are going to have to do some kind of elevation difference scaling to reduce distances to the system, period. Well one exception is if the elevation varies linearly or in a uniform curve that a projection surface could be made to follow Like being 5000 feet on the east rising evenly to 7000 feet on the west side.

This is one of the falacies of the new Maine 3 zones. They were trying to eliminate or minimize the need for scale factors (multiplicative challenged), but oops, even Maine isn't flat.

All you can hope for is a coordinate system that will give you reasonably close to ground values. You could quantify PPM's of error for various average elevations and whether using such a system is feasible is ultimately dependent on the surveyor understanding when it can no longer be effectively used.

re: 1) I will get back to you on the orientation thing. It would seem odd to me to have grid mean different things in different parts of the software and particularly odd to have grid in ground definition to mean orient "this system to this system" self referential type of thing.

If what you say is so, then selecting "grid" actually then orients N to true when you check it, then what does it do when you don't select it?

And even if the function is that confusing and messed up, and grid means true somehow and assuming any aspect of the orientation dialog functions work properly then you can orient to SPC grid using either the orient to a point and select a point you have grid north of your orig, (real SPC grid that is) or dial in the mapping angle at the origin point. Either of those options might require an external program to compute the theta I would have to play with it to see.

I would prefer to actually test what happens before going too far in my response however, so will do some testing to clarify what I see going on.

My reality check is bouncing I guess...

- jlw
Modified By jerry wahl on 12/6/2001 at 3:16 PM

1) I confirm that the "orient to grid" in the ground system definition dialog actually orients to geodetic north at that point. This is undoubtedly due to the way ground was implemented in some fashion on top of a grid created at ellipsoid possibly using code already in the local coordinate feature.

But how as users would you be expected to know that? To the user orient to grid means the very opposite of orient to geodetic North. It may have been derived from the internally created local grid that was just created 0.2 seconds before when I defined base point and false E and N which was oriented to geodetic north.

2) Easy work arounds to orient to SPC grid north. Since AS is so easy to change project setup.

Method 1

a) At any time before you want to set up ground system, instead go to project settings and define your SPC grid.

b)Now go to control workbook control tab and define your base point lat long or sPc if it is not one you already have in the job.

c) toggle coordinate display to SPC (you can always toggle between defined grid system and geodetic)

d) enter a new control point call it something like GRID and make it's X the same as the bases X which is right there on the screen. And enter a Y value a thousand or so meters Northerly. (if you do this right you can get the new points default x and y to be a copy of the base point and all you have to do is edit the y value)

e)go back to project settings and change system to ground select new and hit the [...] button to define new ground system

f)name it

g) pick your base point by ID and put in the false easting and northing you want it to be.

h)select the second option under orientation (by point) and select your GRID point that we defined in d). Since it had the same x value as the base point it is a point SPC north of the base.

i) done and you should now see in the workbook for control or points values of false easting on the GRID point same as base point.

Method 2

a) same as a above defining SPC system.

b) create control point for base point if you are not using one of your observed stations.

c) run a report, with point listing which should include a point list with coordinates, mapping angle and grid scale factors.

d)write down mapping angle on a scrap of paper. Note that this may be in oddball units, one would expect mapping angle to be in degrees minutes and seconds, but when I tried it it was in degrees minutes and decimal minutes. Be careful to note the sign (plus or minus)

e) with a calculator or a good head convert to degrees minutes and seconds. If it is negative add it to 360 to give you a positive value such as 359-42-33.5 for example instead of -0-17-26.5 or -0-17.442 decimal minutes format.

f) go back to settings on the project and define ground system as before in f) and g) in the first method.

g) in orientation select last option and enter in the mapping angle value from e) this entry field is sort of tricky but fiddle with it and you will see how it works.

h) done, check in workbook points or control tabs.

Doing a method 3 with local coordinate option may be a bit more tricky, haven't tried that yet, but these methods seem easy enough so why bother.

Yes, a new radio button for "orient to SPC grid" would make it slightly easier, along with re-labeling existing button to somehow convey that functionally it means orienting the ground system to geodetic north, and also the "angle" option means angle from geodetic north.

- jlw

If I had my druthers, the grid-to-ground setup in Solutions would take the form used by Star*Net. It's clean and logical, and looks like this:



I'm sure there are copyright issues to be worked around regarding the specific layout of the dialog box elements, but I'm also sure that Ashtech programming staff could replicate the functionality without stepping on Ron Sawyer's toes. (Imitation is, after all, the sincerest form of flattery.)