Confusing discrepancy between GPS and Total Station measurements.

Have you taken into consideration the height above sea level? The scale factor is correct only at sea level height and will need to be corrected to the height at which your are observing. Your software might be compensating for this on the GPS readings (since the GPS will be providing information on the height above datum) but not on the total station data.

You are lying to yourself.

GPS without a scale factor should be used to compare with ground stations.

A traverse without scale factor is used to compare with other ground coordinate systems.

To get from one system GPS/Ground), only apply a scale factor once and apply it in the right direction. If you are at any elevation, the GPS to ground process should increase coordinate values. At or near the ellipsoid/geoid base elevations your scale could be up or down. You have to give yourself the confidence that you know which is which as you have given insufficient information for anyone else to determine.

Certain GPS information requires no scale factor to compare with ground traverse. Typical GPS post processing software should give you your GPS vectors. These are actual ground to ground vectors in XYZ. These can be compared with your traverse slope distances, which may require you to include HI & HR heights, but within the error budget these are usually un-noticeable. You must carry elevations of your traverse point if you ever compare it to GPS, and it is a significant check of your project accuracy.

The fact that your angular comparisons are reasonable tells you your problem is in your application of scale factors. To allow yourself to rely on machine/manufacturer defaults implies you do not sufficiently understand surveying.

Paul in PA

mrewenmacdonald, post: 411135, member: 11707 wrote: I don't know if my GPS shots are off or my total station traverse is off... I have checked into the surrounding control points with great accuracy using the gps Hey guys I recently went on a trip to Scotland to traverse around the old family farm and upon returning I have realised that the static GPS data which I have taken on the same points has shown up with large discrepancies in distances (Between Static + yet strangely enough very small angular angles.

I have very accurate equipment (2" Leica Robotic Total Station, high precsion tribrach carriers, etc...and Leica GS14 gps receivers so I'm not at all worried that the equipment is the issue) and I have been as careful and methodical about my setups and keeping them perfectly centered and leveled as they can be... so I'm not worried about the quality of the setups....

My guess is that there is something up with the scale factors.. I have static shots in my 3TM coordinate system using a scale factor of .9999 which is the default scale factor for that projection.. everything ties in great with gps (I have checked 6 points all over site).

I have also run a traverse through the site and the major control points using NO COORD SYSTEM and a scale factor provided to me for the project of 0.9998145 ... and using the known backsight setup method, I have setup and tied in control points to find little error with that setup...

So now I have no idea whether my total station is lying to me or my GPS is lying to me. Any Ideas? ways to figure out which it is?

The 0.9999 is the scale factor on the central meridian. The further away you go from the CM, the larger it gets.But, the best way to compare GPS to TS is to reduce the TS data to mark-to-mark values (both distances and zenith angles). GPS software usually provides DX, DY, DZ, which are the components of the mark-to-mark vector. The gps distance=sqrt(DX^2+DY^2+DZ^2).

John Hamilton, post: 411193, member: 640 wrote: The 0.9999 is the scale factor on the central meridian. The further away you go from the CM, the larger it gets.But, the best way to compare GPS to TS is to reduce the TS data to mark-to-mark values (both distances and zenith angles). GPS software usually provides DX, DY, DZ, which are the components of the mark-to-mark vector. The gps distance=sqrt(DX^2+DY^2+DZ^2).

John, And you know this how?

GPS coordinates are GPS coordinates, either in XYZ, or Lat, Long and Height, no scale factor is involved. Having GPS coordinates in an SPC system means they are not GPS coordinates. Be that as it may, no scale factor is applied until you know what you are doing with those coordinates. Total station coordinate mark to mark values, are also DX, DY, DZ .

Paul in PA

WTF?? Your comment does not make sense

Paul in PA, post: 411196, member: 236 wrote: Having GPS coordinates in an SPC system means they are not GPS coordinates

Or, it means they are just coordinates, sans metadata, and datum....

If you want to compare GPS and EDM measurements, datum and coordinates do not even enter into it. At all. Period. Mark to mark distances are independent of datum (and coordinate system), that is why I always say it is the best format for processing (and archiving) data.

JH is correct - as long as you ensure that your software has given you the ground distance and not the projection distance - too often I see that the distance quoted is, in fact, the distance on the projection.

As you appear to have good agreement on the figure shape (you say all the angles are close) then the discrepancy must be connected with the scale factor.

I would not call it a ground distance-there is confusion in that statement in that it could be at the elevation of the standpoint, or the forepoint, or the mean elevation, or the...

There are many possibilities of ground distances between two plumb lines, actually an infinite number if one goes out into space, granted the range is quite small if you restrict the possibilities to the elevation of the high point and below down to the ellipsoid.

There is one and only one mark to mark slope distance between two markers. I don't think very many software packages give this value (some probably do), but it is not difficult to calculate. As SOP I read all of my terrestrial data into a database, and reduce it there with a software routine. The adjustment packages I use (Geolab and Star*Net) both handle mark-to-mark quite well. Of course, all of the above assumes you have HI, HT, and zenith distances (or elevation differences).

Here is a document I wrote many years ago about EDM reductions, etc. I just created a new pdf, it was originally written in an older version of word, I tried to fix the obvious formatting errors, but may have missed some.

http://www.terrasurv.com/edm.pdf

John Hamilton, post: 411247, member: 640 wrote: If you want to compare GPS and EDM measurements, datum and coordinates do not even enter into it. At all. Period. Mark to mark distances are independent of datum (and coordinate system), that is why I always say it is the best format for processing (and archiving) data.

John,

Let me quote myself: "Certain GPS information requires no scale factor to compare with ground traverse. Typical GPS post processing software should give you your GPS vectors. These are actual ground to ground vectors in XYZ. These can be compared with your traverse slope distances, which may require you to include HI & HR heights, but within the error budget these are usually un-noticeable. You must carry elevations of your traverse point if you ever compare it to GPS, and it is a significant check of your project accuracy."

So are we not in agreement.

Let us consider Mr Ewen MacDonalds questions:

"I have static shots in my 3TM coordinate system using a scale factor of .9999 which is the default scale factor for that projection.. everything ties in great with gps (I have checked 6 points all over site)."

Since he is in Scotland I consulted the Ordnance Survey, 3TM does not register, however there is a TM with CM of 3å¡W, there is also a TM with CM of 3å¡E, the former covers Scotland and the SF at the CM is 0.9996 If the GPS information he has is per those coordinates he may not have elevations.

"Static Shots" needs explanation, are these individual observevations, static processed through a base station system, differential static post processed? Other than multiple receivers, too many questions, no answers.

"I have also run a traverse through the site and the major control points using NO COORD SYSTEM and a scale factor provided to me for the project of 0.9998145..."

I do not know nor can speculate where this scale factor came from, but it is my impression it should not have been used.

Lastly I note that Mr Ewen MacDonald has not checked back in here since posting.

Paul in PA

My question is why are you complicating this? He said he had a discrepancy in distance between total station and GPS. Static GPS implies he has vectors between points. No coordinate system or datum is required to compare these vectors with EDM as I have pointed out multiple times.

John Hamilton, post: 411262, member: 640 wrote: My question is why are you complicating this? He said he had a discrepancy in distance between total station and GPS. Static GPS implies he has vectors between points. No coordinate system or datum is required to compare these vectors with EDM as I have pointed out multiple times.

Static GPS means he had reasonable observation times, but he does not indicate the source of his coordinate values, post processed or otherwise. He has complicated it by including scale factor.

Again I will quote myself from before you first replied:

"Certain GPS information requires no scale factor to compare with ground traverse. Typical GPS post processing software should give you your GPS vectors. These are actual ground to ground vectors in XYZ. These can be compared with your traverse slope distances, which may require you to include HI & HR heights, but within the error budget these are usually un-noticeable. You must carry elevations of your traverse point if you ever compare it to GPS, and it is a significant check of your project accuracy."

Until Mr Ewen MacDonald replies how he determined "Distances" we can do little good here.

Paul in PA

Not to get into what seems to be a heated debate but what the hell. First, to quote a famous geodesist, there is no such thing as a GPS coordinate. GPS or GNSS is just a tool to derive a geodetic coordinate. Secondly, I would say the coordinate system in this case is a red herring.
The vector provided by your GNSS is based on an earth centered/ earth fixed coordinate system. I would make a small assumption that most post processing software take the antenna height into consideration as part of its calculation of the vector. That being said, it should be the same as the unscaled direct 3D measurement derived by terrestrial means. The direction of the vectors will vary but the magnitude should be within the tolerance of the two measurements. To me it sounds like both John & Paul are trying to say the same thing with different words.

Once Mr MacDonald has verified the vectors are similar then he can start playing with the coordinate system and either use a combined factor to convert his GPS derived geodetic values to ground or scale is TS measurements by the appropriate combined factors per line to produce grid coordinates.

I guess my real issue is with Paul and his condescending tone that he often uses when trying to provide an answer to someone's question. He frequently does that, and it always bothers me. If someone asks a question, and I know the answer, I try to provide a clear and concise explanation without implying that the person should not be asking the question, or should already know the answer. There are plenty of things I don't know (see my CAD question from today), and the way Paul answers questions tend to make people not want to ask.

This board is a great place to learn, but not if people are afraid to ask.

John Hamilton, post: 411283, member: 640 wrote: I guess my real issue is with Paul and his condescending tone that he often uses when trying to provide an answer to someone's question. He frequently does that, and it always bothers me.

I can think of at least one other regular poster here.

[MEDIA=youtube]RNHJJp78w2Y[/MEDIA]

John Hamilton, post: 411283, member: 640 wrote: I guess my real issue is with Paul and his condescending tone that he often uses when trying to provide an answer to someone's question. He frequently does that, and it always bothers me. If someone asks a question, and I know the answer, I try to provide a clear and concise explanation without implying that the person should not be asking the question, or should already know the answer. There are plenty of things I don't know (see my CAD question from today), and the way Paul answers questions tend to make people not want to ask.

This board is a great place to learn, but not if people are afraid to ask.

I believe this was the initial answer he needed:

"The fact that your angular comparisons are reasonable tells you your problem is in your application of scale factors."

I guess that means I am the Grumpy Old Man:

"To allow yourself to rely on machine/manufacturer defaults implies you do not sufficiently understand surveying."

From what the Ordnance Survey tells me, the default scale was wrong; 0.9999/0.9996 results in a 3/10,000 error.

That should get some ones attention.

(Total, guilty as charged.)

Paul in PA

'3TM' according to Google is a co ord system used in Alberta! Whether this can be used in Scotland I don't know. I think it would help everyone including Mr Macdonald if he came back and rewrote his question a bit more logically with more info on the static occupations and post processing.

Artie Kay, post: 411300, member: 3428 wrote: '3TM' according to Google is a co ord system used in Alberta! Whether this can be used in Scotland I don't know. I think it would help everyone including Mr Macdonald if he came back and rewrote his question a bit more logically with more info on the static occupations and post processing.

I thank A.K. for that info.

The Ordnance Survey used in UK references UTM zones of 6å¡. Alberta references Transverse Mercator zones of 3å¡ used for county size projects. The zone used in Alberta would not be used in Scotland, but some factors would remain the same. It might be reasonable for such a zone to have an SF of 0.9999 at the CM.

Given that, as J.H. pointed out, GPS values are not coordinates, however coordinates can be readily calculated from GPS positions. My personal post processing softwares do that. OPUS regularly gives me GPS positions in 4 different reference frames and coordinates calculated in UTM and SPC. I can pick which SPC zone for OPUS to use and regularly work in an area where I could use PA N SPC, PA S SPC or NJ SPC and do use my three favorite CORS stations, situated one each in each of those three zones.

Paul in PA

As a follow up to my above post, I have listed the SPC coordinates for my site control point on a project of mine near the limits of those three SPC zones.

PA S SPC 570695.717 N 2679664.836 E 717.984 Ortho 0.99998642 SF 0.99997093 EF

PA N SPC 267358.189 N 2679671.878 E 717.984 Ortho 1.00000193 SF 0.99997093 EF

NJ SPC 743101.943 N 304568.895 E 717.984 Ortho 0.99994021 SF 0.99997093 EF

Paul in PA