Satellite display on 66i

You are still confusing the Reference Frame with the 2D projection that you can see and call the “chart datum”. This is not about transformations to, or between, 2D projections, “charts” or “maps”.

The Reference Frame is different, you can’t see it. It lives behind the scenes but it is extremely accurate. As the name suggests it is a 3D frame that has exact reference points at its origin and all around it. Some of the known reference points are fixed to the earths surface (monitor stations) and others are projected out in space as satellites which tell us exactly where they are in the frame. And your device does measure to these, and so it is linked to the ground references. The only issue is how rubbery these measurements may be to your real location.

The basic differences between accuracy & precision are well understood. And the GNSS world takes that further with the primary focus being on the accuracy, the “where am I”, closely followed by the “how closely” and “how confidently” aspects. Much better than simple +/- precision. So the accuracy in GNSS is implicit, and measurements, testing and statistics are against real world surface reference positions which are then compared to the receivers view on where it thinks it is as calculated from the reference framework above.

So it's not a matter of simplistic accuracy vs precision, think of the 95% estimate as giving you both in a more relevant way to this use case.

Back in the days of Selective Availability when only GPS was available and the public signals were deliberately skewed to wander around 100m or so, groaning about precision and accuracy was fair. Times have changed, SA has gone, technology has improved, and extra constellations are available with more satellites in view and better geometry more often, and importantly additional and different frequencies have been introduced that help address the key ionospheric issues.

In case you missed it look again at the overview explanation on the measures from the European Space Agency I posted earlier: https://gssc.esa.int/navipedia/index.php/Accuracy

Here’s an extract: “The accuracy of an estimated or measured position of a craft (vehicle, aircraft, or vessel) at a given time is the degree of conformance of that position with the true position, velocity and/or time of the craft. Since accuracy is a statistical measure of performance, a statement of navigation system accuracy is meaningless unless it includes a statement of the uncertainty in position that applies.”

And here’s an example of an IEEE assessment of GNSS receivers in real world road applications: https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8421016

An extract:

“A. HORIZONTAL ACCURACY

The assessment of position accuracy across all the receivers and environments using an accurate RTMeS was an important goal of our measurement campaign. The groups of receivers from Table 8 were expected to belong to distinct accuracy classes, e.g., geodetic to Class 1, automotive with roof[1]mounted antenna to Class 2, and smartphones to Class 3 for the clear-sky scenarios.”

Note in this assessment all devices are considered “accurate” to one extent or another. And they are all considered and extensively measured against positions established on the earth, within narrow road lanes, in a critical safety environment. They are not measured or considered only as a theoretical “distribution” floating at some unknown point in space. And this assessment has been completed by professional engineers.

how do I confuse some 2D ?? I am not from 'flat earth' club!

Every chart datum, is 3D. It does not matter how old it is, as far as it does consider earth being something round more or less. I have so far never heard of any 2D chart datum and can not understand the use of such. (*)

Chart datum always contains x,y,z relative position of the center, diameter and flattening. As flat charts, meaning 2d projections need to have some properties e.g. keeping angle correct or other correct relative size of areas, they will be adjusted to a spheroid first and from there all those known projections as mercator, gnomonic, cylindrical and what ever can be easy calculated.

The reason why there are still many chart datum in use even when we could use basic WGS84 everywhere, is that in some local areas it needs local 'best fit' spheroid for generation of flat map pictures. But it is still a spheroid, a round ball, it has x,y,z position of the center, it has diameter, so nothing 2D.

All other texts you collected describe measurements of accuracy of gps measurement *against a fixed, previously defined point on the surface*, saying basically that accuracy does not exist or is meaningless unless tested against predefined value.

So where is really the problem you see?

* ok, our search teams do sometimes maps by hand, simply going 200 steps in 90deg with compass, then 300 steps in 180 deg etc, this will certainly result in some pure 2D map, but this is not a chart datum.

None of the “every chart datum”, “chart“ (flat), “adjusted to a spheroid”, “many chart datum”, “local 'best fit' spheroid” etc. has anything to do with how the receiver initially derives its position.

The positioning only uses the WGS84 ellipsoid (spheroid).

Everything else would come into play later depending on how you configure the receiver to localize its representation of the position and 2D projections.

can still not understand why you have some problem with chart datum. This exist for hundreds of years and the simplified calculation for conversion come from something like 1930ties.

I might be not uptodate with the most recent gps receivers, but when I did build professional gps trackers for railways some years ago, there was nothing coming out of the receiver chipset unless we selected in the 'user application' script what we want get as results. We had to select some of the chart datum incl wgs84 or noting came out at all,  no wgs84, nor anything else. All we could observe  was for us unreadable stream almanac and other broadcast after the code of the satellite was locked as the actual processing part did not do anything useful. Clearly, the almanac positions need to have some rational information and this would be described in wgs84 to make things simple and universal, but later time differences and thus repeated try and error between estimated distance represented by previous time difference  will be continuously corrected  by next measurement etc.

We had a manual and software and clear instruction to select a predefined chart datum or there was a possibility even enter own parameters. Only then some readable output could be obtained.  Certainly there are receivers which have wgs84 output simply as the default setting, but this does not need to be so in each case.

support.garmin.com/.../

Yes, Jordan249. But what does that mean?  Read literally, it is preposterous except when the distance is great enough to include the moon. 

Like much of the rest of the manual, that paragraph is deliberately vague. It was written by someone who did not know what the uncertainty length represented, much less the assumptions or reasoning behind it. 

I have abandoned hope of getting an answer. For all I know, the uncertainty length might be just a constant divided by the total satellite signal strength.  Without an articulated meaning, the number is meaningless. 

Thank goodness it’s not that important. 

skyeye said:

can still not understand why you have some problem with chart datum. This exist for hundreds of years and the simplified calculation for conversion come from something like 1930ties.

The problem with the various datum's is that they add their own error to the position coordinates you are being presented by the device. And with today’s technology improvements this additional error is now becoming relatively significant. In some cases the datum error can be even greater than the device’s own positioning accuracy under ideal conditions.

Given the discussion is about accuracy this is important.

The device positions itself within the ITRF reference frame using the ECEF 3D coordinates, but we are humans and want 2D coordinates to reference on our maps. So the receiver next has to do a transformation of those 3D coordinates to whatever datum and 2D projection we have selected.

And there are many issues that arise when trying to do this in a consumer handheld.

1. To do it accurately requires applying either a sophisticated 7 (or 14) parameter transformation formula, or doing a lookup in a shift grid. To give you an example here's a summary and our guidelines for doing it here for our GDA2020 datum:

https://www.icsm.gov.au/datum/gda-transformation-products-and-tools

https://www.icsm.gov.au/publications/gda2020-technical-manual-v17

The reason for these procedures is that there are differences and they vary across the map grids.

Our shift grid here has over 5 million points and takes a minute to load into my laptop application so it’s clearly not happening in the Garmin device. So, by necessity the consumer device applies the same simple summary offset to all coordinates to approximate all of this and you live with all the resultant errors and have no idea of the magnitude or where they are.

2. From the day this datum offset is fixed and released with the device these errors grow. The reason is tectonic shift, most local datum's are fixed to the plates and that land along with you, and all the survey marks on it continue to move away relative to the GNSS positioning framework. And the drift is not even across the plates, they distort.

As an example, our previous GDA94 datum here had accumulated errors of around 1.5 to 1.8m (depending on where in the country) until we decided that it was too much and switched to our current GDA2020 to again be coincident with WGS84. However, the same issue remains as they both continue to diverge on average around 7cm per year.

Another example, in the US the current NAD83 datum has 3 different versions, one for each of the applicable tectonic plates there. And that datum also has had numerous revisions to realign it for GNSS. The 66i has only one choice available to select NAD83. Which one is it, for where and when?

What is the current error with your own datum and how do you track the variances across your data collected over time? If you navigate back to old waypoint you are unlikely to be at the same point on the ground because it's moved.

Testing with my GPSMAP78csx showed the embedded datum offsets haven't been updated with the firmware releases. And why would they? Complex and costly for a consumer device to make it more consistent for new way points but at the same time making it less consistent with historical data. So no overall benefit.

 3. On top of all of the above there can be other issues. As an example here in Australia my testing indicates our new GDA2020 datum has been incorrectly applied into (at least) 66i. Our GDA2020 EPSG definition and shift grid were released to the world intended as a shift for migrating data sets from GDA94 to GDA2020. Garmin (and other parts of the industry) applied that into devices and software as a datum, but because the definition references GDA94, and GDA94 was originally and is still defined as coincident with WGS84, if you select GDA2020 the coordinates as a result now get pushed away from WGS84 by the same 1.5 to 1.8m error that it was intended to remove. So coordinates provided in both datums are now wrong. For software there are now workarounds, and I can get around it in the 66i by simply leaving it in WGS84 and treating those coordinates as GDA2020. Is your datum correct?

Professional equipment gets around all of this by applying your own time dependent datum and grids for your area and updating them to the device. There are utilities provided that create these for the area and date you specify (using the transformation parameters from the manual above). So if you are post processing and not real time corrected via RTK they just shift the datum to where the plate happens to be at that time and place and the device working autonomously same as a Garmin displays and navigates to coordinates in that datum correctly. I configure these either for a particular project or otherwise generally create batches for 6 to 12 month periods to save time.

So for your favorite datum if you haven't properly tested your device against a known survey point in that datum, then if you use that datum you have no idea if it’s correct or incorrect, or by how much, and where.

yes, right

the use of chart datum which does not actually include proper geoidal height information is purely for practical purposes. They use rather additional height information referenced to a single or multiple local point.

Practical reason to use local chart datum: I was asked to supply information where , meaning on which rail track in a train station with 27 rail tracks a certain vehicle is located. As they did have paper maps of all the rail tracks, but all was definitely older then any satellites, then the use of the chart datum in which the maps were drawn is optimum, use of wgs84 contra productive in such case.

Other places need to use it if they want produce correct projection maps. Known is for example area around japan. Due to big geoidal height corrections to ellipsoid, local chart datum with smaller diameter and shifted center is needed, otherwise derived 2D projections a mercator and other would not be useful. Clearly, small areas and single points can be perfectly described in wgs84, but when it comes to constant angles or proportional areas, this local chart datum is needed. I remember there was a note printed on some paper charts on ships stating that the position reading from  wgs84 is 785m in 120deg from the position on the chart. They could have simply print the lat/long grid shifted on the maps, but this would not be correct over larger area, the proportions will not be maintained in the 2D projection.

One opposite case came up on swiss-german border, where the task was to build a bridge over a river. On each side, they build a support for the bridge, germans on german side, swiss on their side. When they finally attempted to lay the prefabricated steel bridge there, they found out that it does not fit, most deference was in the height of some 37cm. Yes each side was using their own chart datum with it sown height reference. Here would the use of common wga84 help as it is small spot, no problems with distortion on any paper chart.

But in hand held devices, all this is rather irrelevant, as regardless of what chart datum you select, it still can not tell you anything more or better. It can only take data from the broadcasted effemeries and attempt to measure the distance. As it does not know what the distance really is, it can not say it is correct measurement or not. There is nobody here to tell what the distance is really.

And here we are back to start. Any explanation, even those in that Garmin describes how accurate the device is (linked by Jordan249 above) are pure nonsense. Such texts are written for consumers who want to hear this. This is matter for marketing and general customer wants to hear that he has the better, the stronger, the faster one

“User accuracy refers to how close the device's calculated position is from the truth, expressed as a radius.“

https://www.gps.gov/systems/gps/performance/accuracy/

“User accuracy depends on a combination of satellite geometry, URE, and local factors such as signal blockage, atmospheric conditions, and receiver design features/quality.”

https://www.gps.gov/systems/gps/performance/accuracy/

support.garmin.com/.../

support.garmin.com/.../