Experimenting with the Ashtech Solutions coordinate systems particularly the Ground settings. It appears with this it will scale the vectors to MSL but not at the elevation. Ie: 700ft +/-. It applies the Scale factor but not the Elevation factor. So to get a surface/ground measured inverse in my cogo program I still have to apply the Elevation factor.

I must be missing something. If I still have to scale by the Elevation factor what advantage is it to apply one factor over a single combined scale factor?
Rb

Are the Solutions ground distances consistently coming out short Vs the horizontal EDM distances? This is what would happen in most surveys if Solutions was not applying an Elevation Scale Factor, and is instead producing the Ground distances at Mean Sea Level only. How much does the distance difference Vs EDM convert to in ppm? How long are the EDM distances?


BR, Richard

I was using an 8 mile baseline we have between our office and my house. It appears to only apply the scale at Mean Sea Level only. After you choose ground under coordinate system, and once you double click on a point in the map veiw and look at the elevation and scale factors under the position tab you see it only applying at MSL and not at the elevation. I believe I have checked myself by applying the scale factors manualy in my cogo program.

I did a test and confirm that what I got is not corrected for the elevation factor. So that really really is NOT GROUND! is it? Now maybe there is some process, check box, or whatever that I missed. I will have to go back through the help files before I can pass final judgement.

At 5500 feet it makes a difference...

j. wahl

I still contend, after a year of using Locus system, that it's much better to leave the post processed gps points in grid (or geodetic) in the processing software. It's a really simple process to export the coordinates as an ascii file to a cogo package for scale, translation and rotation to ground.

I may be totally mistaken, but would suppose most surveyors that invest money, time and training in the use of gps equipment and software also already have at their disposal a cogo package that can handle these routines.

J.D. Billings, TX RPLS

I guess I'm a little irritable this afternoon. I don't need the ground feature, I have cogo's that do everything I want straight from GP's or SPCs. but if the function is in there it should work right shouldn't it?

You know someone is going to create problems if they aren't aware of the issue and thinks they have ground data and they don't and for some reason never has a double check on it.

Jerry,

I agree completely. If the routine is in the software, it should work properly. I also believe (not you or me included) there are too many folks that totally depend on someone elses "software" to do exactly what is intended. I personally lost my confidence in "perfect software" in 1981. Found too many bugs for me.

I think Ashtech went to extremes for us (Locus users) during the grid to ground discussions last fall. They may have been better off leaving that conversion routine to the cogo software folks. But, I think Ashtech has given us some extremely valuable software to work with.

J.D.

Remember you are NOT reducing to Mean Sea Level (MSL). MSL is a local effect and is defined only in the vicinty of a tide gauge. Geodetic coordinate systems (e.g., lat/long, State Plane, UTM) are defined on the ellipsoid, so in addition to your height above (or below) the vertical datum (NAVD 88) you must also include the geoid height in your computations.

JD... after discovering that the GRID option did not in fact give you grid bearings .. I have been doing all my grid to ground conversions in starnet as before.. Its still a great software package..

BTW am waiting on my new grain mill and plan on starting up the brewery in a week or so.. got any fresh stumpwater? or is that an oxymoron?

Steve G

Steve,

I started out by exporting my SPC's as an ascii file to Carlson Survcadd and doing my grid to ground conversions there. I input the combined scale factor from either a central point or average of some or all network points, rotate, and finally translate to something in the 10000/10000 range. Some projects we have decided to leave entirely in grid, but those that we know will be output and or worked in surface are immediately converted to surface so as to reduce the possibility of error. I just figure it's best to leave the SPC's or geodetic coordinates alone in Locus processor (or now Solutions) for future use of those files.

As for the Stumpwater Brewery, word has it that production may resume next Saturday A.M. and continue till next Saturday P.M. Will probably "feed the fungus" Monday night after a 3 month sleep in the fridge.

J.D.

To the appearance that the ground projection in AS is at the ellipsoid and NOT GROUND? Are we doing something wrong or is the software in error?

Contact Tech Support at support@ashtech.com or 800-229-2400.

Although Thales Navigation sponsors this message board, it's intended as a user group sort of thing, not as a primary tech support point of contact. Thales Navigation doesn't formally monitor this message board, and does not have editorial control over content.
Modified By Brian Ewing, PLS on 9/27/2001 at 10:05 AM

Jerry

I have not had the chance to check directly with a sunshot (no sun) but in checking with prior jobs (indirectly not sta to sta) it appears that the Grid Brg function in AS actually gives what I always called astrominic (what I would get with a sunshot) which is the diff of the convergence. I think the software is OK its just mislabeled as being Grid. Correct me if I'm wrong... I hope to check one next week.

JD.. do you keep wort in the fridge for your starters?? or is that "stump fungus"...

Steve G

Send me some data, and I'll see if I can duplicate these Grid To Ground issues.

I'm interested in the raw GPS data, the Solutions project file (*.spr), and the measured horizontal EDM distances that were used to compare the Solutions Ground distances against.

It would be best if the GPS data was from a network at a high elevation (at least a thousand feet) that has some redundancy in it. Also, EDM distances that are part of a closed traverse would be the most helpful.

Phil Stevenson will be taking an active role in monitoring the RPLS post and answering questions. I will continue watching the post and answering questions along with other employees here at Thales.

The fastest way of getting a response is probably via e-mail or telephone at the numbers below.

Best regards,
Richard

Thales Technical Support
1-800-229-2400
support@magellangps.com

support@ashtech.com

is actually the correct support e-mail address.

Richard

Jerry,

Richard and I have had an extended discussion about this grid-to-ground issue this morning. He has spent some of the last few days working with projects and trying to make sure that what is being said on the message board is also what he gets.

His checks indicate that the software does end up with coordinates on the ellipsoid so even though the adjustment report gives you an elevation factor for these points you still end up with coordinates on that ellipsoid, well below the 5500 foot elevation you were talking about. I hope you read his request for some of your examples in the form of data files.

While I understand that the idea behind what Ashtech has done was to try to give surveyors a set of coordinates that will let them avoid the use of scale factors I personally would rather stay with the SPC or UTM coordinates and try to get the COGO, GIS, and CAD makers to automate the process of getting ground distances, areas, and volumes from the grid coordinates.

Why? Because our objective ought to be putting surveys into digital maps. As the coordinates for the projects get modified the connections between projects fall apart. If the COGO, GIS, and CAD software would take care of those grid and elevation scale factors while we all worked with coordinates that maintained their relationship to the National Spatial Reference System our ability to share digital data, and incorporate that data into community and facility mapping, would be improved.

Truthfully the message board is not ignored by the Ashtech tech support team. Richard and I can both be found here. When we are not doing other duties we enjoy a good discussion about survey issues as much as the next guy. That you find other surveyors, who are also Thales Navigation employees, making regular posts on the message board says something about how we, as surveyors, want to be a part of the solution. Ashtech Solutions!

If you want an official tech support answer you can even click on Richard's name or mine and you will be sending your message to our tech support work station.

Please take a look at the software position paper that was adopted by the OSLS last year. You can read it on their web page at http://www.osls.org That land surveyor organization has told the software makers they want to see this problem handled by the COGO, CAD, and GIS software.

Oops guess I generated attention. I was not intending to be critical or negative in any way in my subject line. I also want to make it clear that I don't think the board is neglected by ashtech and realize that people get involved in other things even for weeks at a time, etc.

But I did want to make sure that someone was aware of what could be a significant issue before it starts to drop down the thread and get lost in time.

As I mentioned initially, I have other means to deal with the grid to ground issue and so can work direct with lat/long values or state plane with facility. This issue has zippo effect on me or the people I work with.

However because this GROUND issue is something I expect a lot of users wanted and will therefor attempt to use, it seemed worthwhile to verify how it works so that everyone understands, or what we are missing so that future users can be advised, or if it is wrong get it remedied.

These kinds of user boards are great resources for such user to user advise and information that can provide leveraging everyone's experiences towards better use of the tools provided.

In this case it is not my issue except to help other's or ashtech understand what is happening or dispell our misunderstanding for future reference. If I misunderstand it I would expect a good percentage of other users would also.

The test I ran does not have redundant vectors and does not have EDM checks. All I felt was necessary was to varify the coordinates of stations in 3 systems. 1) the geographic coordinates NAD83, 2) the same points exported as SPC's, which I assumed were computed correctly, (however I would be glad to check them also.) and 3) a ground system based on one of the stations and inversed in plane xy form. elevations or z values ignored.

The average elevation of the test was about 5550 feet or 1690 meters ortho near Denver.

Whether the data represent fictitious or real data should not be relevant as all I am checking is the transformations between these 3 systems.

I will get back with my test example worked out and documented if I can.

If on the other hand we are just dealing with semantics and you guys think that coordinates at ellipsoid are what you mean by GROUND, I will just respectfully disagree and go on with my life as before and no example is needed. This seems to be what Phil is saying, confirming that the coordinates are at ellipsoid which confirms my test and the experience of the original poster of this thread.

If everyone's answer is (as it seems to be), to do it some other way, (which I do) then I would suggest the feature be removed from the software as my insignificant comment and we can all move on.

Modified By jerry wahl on 9/27/2001 at 1:54 PM

The riddle of GROUND has been solved, well more or less anyway. This afternoon I began to put together some examples to show the problem I perceived from my first test. To make it simple I was created data points as control in the general area I had tested before Colorado Central Zone, etc.

First problem I encountered is that there appeared to be nothing wrong. The ground system produced correct inverse distances when compared to both hand and machine reduced SPC's and 2D geodetic inverse programs.

Perplexed as to how I was now getting things to work and not willing to immediately assume I was nuts, I produced another example in another part of the zone closer to my original example. It also turned out fine.

In both of those cases I simply printed out system reports and hand inversed the ground system by using dist = SQRT(dx^2 +dy^2) where dx and dy are the differences in x and y between the two points. These checked as stated above.

Now realizing that I must have made some monumental error in my original test project, I returned to the original test and following the same procedure I got correct results this time.

Well now I could tell I was likely to really be embarrassed for making such a mistake.

I continued on since I wanted to find out really why or how I could have done so, I decided to check my original data. I had done one thing different, instead of doing a hand distance comp on the ground coordinates I had used the export option.

I had an already built one to create autocad script files of point x,y,elev format. So I used it and then brought it into autocad, changed all the points to zero elevation so as not to get slope distances, and let autocad give me the inverse.

YES IT WAS WRONG! As in my initial test, even though the coordinates I had checked by hand were right!!!.

Now I began to wonder how this happened. Examination indicated that the coordinates of my 2nd point (the first was 10000,10000) in Autocad were different than that shown in Ashtech Solutions!! I must have goofed big time but then I decided I had to take a look at that export function.

THIS IS WHAT I DID WRONG. The export has very nice functionality that allows you to create files from the data in your job in all kinds of formats. Fields of data are selected from a pulldown drilldown list and you can control the formatting a thousand ways. However my selection had been

TEXT and the text POINT followed by a space and then
GRID Easting comma GRID NORTHING comma ortho elevation.

It came out into the script and into autocad with coordinates that appeared to casual observation to be the GROUND values, i.e. in the 10000,10000 range I had set up. BUT they are NOT! the same. They appeared to be the evil ellipsoid values we talked about this Thursday morning and different from those shown in Solutions site tab.

But wait this is still not a mistake, it is probably a feature, as a closer look at the fields that can be used to create export formats there is ANOTHER set that is specifically LOCAL/GROUND easting and northing, etc.

It is readily apparent that I should have used those as they do in fact write out the GROUND X,Y that match those shown in my SITE data table!

Problem solved. Export format GRID creates a possibly undocumented ellipsoid coordinate under the ground system that is almost the same and fooled me into assuming it was.
Export format from the LOCAL/GROUND GRID list gives the coordinates desired and life is now back to normal.

So that is what happened, if it makes sense to anyone.

The ground coordinate feature creates a coordinate system at the base point you select and the distances at the elevation of that point are then correct for an area around that point.

If these coordinates are to be exported the user be aware and create specific export templates that use the correct fields and no
Modified By jerry wahl on 9/27/2001 at 10:39 PM

I compared some horizontal EDM distances at an ellipsoidal elevation of about 5500 feet against Solutions 2.50 ground distances between the same survey points. The Local Ground Northings and Ground Eastings were being scaled by the Elevation Scale factor in Solutions 2.50.

The Local Ground Northings and Eastings that were exported in ASCII format, were scaled by the Elevation Scale Factor. The Local Ground Northings and Eastings were not at a 0 elevation on the ellipsoid.

If anyone is still seeing problems with these Local Easting and Northing coordinates, please let me know and I'll look into it further.

Richard