Position Ambiguity [was] Re: [aprssig] findu.com Location off by 100 miles.

[KC2MMI (Jared)]

Steve, Bob-

"One must assign  a specific lat/lon to obtain a plot."
Not true. Navigators have always known their position has limits (ambiguity or
uncertainty or circle of error, call it what you will) and have always made
plots with and despite this.

 "The world has moved on to "I'm right here", your concept of "I'm somewhere
over here" is so 20th  century ;-)"
And as with many things, the popularization of navigation has to some extent
ruined the art and science of it. This does not mean we need to accept
"MacDonald's" as being the definition of a hamburger. Catering to the least
common denominator is cheap and easy, but not a worthy goal.

"No, Kenwood implemented position ambiguity as best they could"
 I'd disagree with that and suggest that here Bob has given us a solution in
Kenwood's error.

"Regardless, things like Google Maps have no concept of ambiguity.
""No, but applications that use those maps should.  There should be
a clever way to work around this.""

There is a clever way to work around this, APRS transmission of ambiguity can be
fixed and I suggest it can be fixed fairly simply. Of course that's only half
the problem, the failure of almost all software writers and self-styled digital
mapping companies to allow for the presentation of position ambiguity, or circle
of error, should be considered shameful.

Within APRS, if I understand the spec, or at least within Kenwood's adaption of
it, ambiguity is presented by simple truncation to the rightmost digits.
Suppose, instead of truncating them, we filled those positions (or at least the
first one of them) by "A" instead of a number. "A" for "Ambiguity here!" The
APRS packet would esssentially be the same, all that is needed is to have the
software parsing the packet become a bit smarter and say "Oh, look, an
"A"Ambiguity marker here! Pass it on."

And then, of course, it is up to the application to decide whether it will crash
(more sloppy code), report bad data (time to update the code), or perhaps even
better yet, simply display the "A" in text displays, and render it as a circle
of uncertainty in mapping displays.

Until *all* the applications that use GoogleMaps, NavTeq maps, TIGER databases,
and other sources of imprecise online mapping stop using "pinpoints" and start
using "blobs", they will remain very impressive kiddie coloring books--but not
cartography. It takes little effort on an author's part to say "Oh, this datum,
this source, is known to have an error of xxx feet, therefore I won't use
pinpoints, I'll use something else." Very little extra effort--and no extra
effort if the author has any professional pride.

Personally (and yes, I've done cartographics) I'm in favor of using position
circles, despite the fact that circles aren't always right, and simply making
them "fade" out from a solid center to a light tint at the edge. A "fuzzy" spot,
which seems to be interpreted by untrained users as exactly that: Something
fuzzy and imprecise.

What say Bob? How would using "A" instead of a "fuzzy digits here" impact APRS?
(And please, let's not go back to freezing everything because the legacy junk
can't be fixed without replacing it. Please.)