position accuracy question

http://www.garmin.com/garmin/cms/site/us/support/searchsupport?search_key=accuracy+circle

        Com'on guy! it doesn't really mean much or anything. It's just a feature
of some GPS model control by software, and if it can didplay different
colors then it can do whatever the programmer programs it.

        I do remember it was part of my old MONO GPS the LARGER circle saying the
destination is inside screen, the smaller means getting closer til it starts
BEEPING (blinking too?)

        Now, with your current Garmin GPS, just toggle between 2D and 3D then you
may see some interesting about the position accuracy.

Am 26.07.2010 09:06, schrieb BWilliams:

you may be right for intersections but a map doesn't only consist of
single points. Look at the street lines lacking much curves.


--

Heinrich
http://www.gartrip.de

map

He's not right about intersections either. If you have a very
detailed map where you are showing the map features down to an
accuracy of 30' then you need to specify each point with lots of
digits for the latitude and longitude. That level of detail and
accuracy takes up more memory - not only because you have more points
to specify, but also because each point needs more bits to hold the
accurate position data.

Retaining the same high level of accuracy of each point when storing a
much coarser map (say where having the features known to within a few
hundred feet is adequate) would be a waste of memory space. It's easy
enough to see this by zooming way in on an area for which you have
both the coarse basemap and a more detailed map (such as CityNav.).
Features such as intersections, turns, etc. won't show up in *exactly*
the same locations on the two maps.

To answer the original question:
The accuracy circle is supposed to be an indication that your actual
position is likely to be somewhere within that circle *as portrayed on
the displayed map*. So inaccuracies in the map data and uncertainty
in the position measurement both enter into the size of the accuracy
circle.

On Wed, 28 Jul 2010 19:43:28 -0700 (PDT), Peter Rathmann wrote:

While that may be true in an absolute sense, it's unimportant in common
application. A typical 32-bit float value has sufficient precision to
mark something to within a couple meters. That's enough for driving,
geo-caching, at-sea navigation, and probably even plowing fields (though
for that you'd probably want to use a paired system with one unit fixed
and the other measuring position relative to the fixed unit rather than
a map accounting for the whole world.) For only doubling your database
size, you can get precision to micrometers, and I can't think of ANY
application that would need more precision than that, even if it were
even possible to use GPS to get enough accuracy to make it relevant.


There's little point in saving memory below two floats per coordinate
pair. Your savings in storage would get lost in the noise within the
rest of the data describing what the pair locates, and the work involved
in having to write your own math packages to cope with non-standard
numeric representations instead of being able to simply lift the IEEE
routines wholesale is not worth the potential savings of even maybe
dozens of megabytes in your mapset, If your mapset is already going to
be big, you save *nothing* making it (for example) 1624MB instead of
1641MB. You *still* need 2GB of flash, 'cause it's cheaper than putting
in 1.8GB.


But the "inaccuracies in the map data" isn't precisely known either,
shrinks all the time, and these days, in most places, is going to be a
matter of "out of date" more than "inaccurate".

--
For every subject you can think of there are at least 3 web sites.
The owners of these web sites know each other and at least one of
them hates at least one of the others.
-- mnlooney's view of Skif's Internet Theorem

on
n a map
y

No, the database to describe a curving road network as well as lake,
park, and other boundaries will be dominated by the point pairs that
specify the locations. Any memory savings in either reducing the
number of such points or the bits required for each point are
therefore very worthwhile. It's the rest of the data that's 'in the
noise'.

No one claimed it was known precisely. But NavTeq only needs to tell
Garmin that the overall average accuracy of the CityNav data is, say
50', and that lets Garmin draw the accuracy circle accordingly after
adding in the effects of the current measurement accuracy based on
satellite geometry etc. OTOH, if you're just using the basemap the
map accuracy might be 200' and the accuracy circle will therefore be
drawn larger.

Things being "out of date" are a separate issue, but that mainly
results in roads missing entirely from the map rather than being
slightly displaced. Relatively few roads are relocated to new
locations. I can clearly see by looking at the consistent tracklogs
vs. the displayed road location that the street in front of my house
is shown as slightly too far south on the current Garmin maps. That's
not because the street has ever been moved but rather because there
are still inaccuracies in the map data.