[aprssig] Position Ambituity in APRS!

Tue Jan 8 19:04:22 UTC 2008

> If I transmit my position to degree precision 
> (for example 35  .  N\083  . W), to plot that 
> "location" on a map, I would mark an everything 
> from 3500.00N to 3559.59N and 08300.00W to 
> 08359.59W, right?

No not at all.  That is the incorrect BOX interpretation which
was never intended.

The original APRSdos plots a circle of 60 miles radius
approximately at 35N and 83W.  A sufficient random offset from
that location would be added so that if there were several
stations all reporting that same position ambiguity, they would
not all appear as one circle but would all be visible.

The circle is not a precise boundary of ambiguity.  It is a
REPRESENTATION to the VIEWER that that station's position is not
well known and its ambiguity is on the order of the size of the
circle presented.

If we had just been allowed to put those words into the spec, we
would not still be having different interpretations for the last
10 years.

> So that would be the possible area (whatever 
> geometric shape it may be) that I can be in, 
> right?

Sorry, wrong.  It is exactlly that missinterpretation that we
are trying to avoid.  

It is not a box.  It is a circular image of a large amount of
ambiguity on the order of a circle of radius appropriate to the
missing digits of precision.

If you want to send a SEARCH box or other precisely bounded
area, then send an AREA object instead.

Bob, WB4APR

> 
> -- 
> William McKeehan
> KI4HDU
> http://mckeehan.homeip.net
> 
> On Tue, January 8, 2008 10:58 am, Robert Bruninga wrote:
> > Welcome to the 15 year debate!
> >
> >>> Is, or is not, position ambiguity at the
> >>> transmit end simply the
> >>> truncation of lat/lon digits?
> >
> > It is not.  It is NOT truncation.  It is simply the
transmission
> > of the AVAILABLE DIGITS to the degree of precision desired
or
> > known.  If you have only degrees, you transmit only degrees,
> > which give a position to the nearest degree (60 miles). If
you
> > have only degrees and minutes, you transmit only degrees and
> > minutes which is the position to the nearest minute (1
mile).
> >
> > If you have a position known only to the nearest tenth of a
> > minute, then you only transmit the degrees, minutes and the
> > tenth of a minute that you have (position known to the
nearest
> > tenth of a mile).  This is not truncation.  It is
transmitting
> > what you know, and NOT implying additional digits of
precision
> > that you do not know.
> >
> > That is all that APRS position ambiguity means.  You
transmit
> > the position only with the number of digits that match the
> > precision that you have.  And you do NOT add precise decimal
> > digits beyond your knowledge.  The position field in APRS is
a
> > CHARACTER STRING that happens to have room for digits of
> > precision down to hundredths of a minute.  It is NOT a
numeric
> > field which many programmers incorrectly implemented.
> >
> >> You have to understand the way Bob's mind works.
> >
> > Yes, it is simple.  If the position is known to be 38
degrees 58
> > minutes, then you transmit ONLY "3858.  N"  It is absolutely
> > WRONG to send "3858.00N". Any middle school science teacher
can
> > tell us that.
> >
> >> This tops my most-hated of Bob's excursions.
> >> The engineering way to handle uncertainty with
> >> position is as has been suggested, a precise
> >> position representing the best guess, and an
> >> altitude-like extension representing the
> >> approximate radius of  uncertainty.
> >
> > Absolutely wrong.  That precise estimate implies a PRECISION
> > that does not exist.  Such simplifications by APRS clones
> > unwilling to properly implement this simplest of concepts
> > undermines the integrity of information from sender to
receiver.
> > If the sender does not know the precise position, then he
should
> > not under any circumstances send it as a precise position.
He
> > should transmit only what he knows so that the recepient
cleary
> > sees the same level of ambiguity.
> >
> >> Google does this, Garmin does this, Trimble does
> >> this, but Bob? To save a few bytes in the protocol,
> >> Bob reused bytes in the lat/lon.
> >
> > Not true.  I did not reuse "bytes". What I refused to do was
to
> > put in higher digits of precision when those digits ARE NOT
> > KNOWN.  To do so would violate every principle of "precison"
as
> > taught in middle school.
> >
> >> His intention was not that this be interpreted as a
> >> question mark in the lat/lon, a literal uncertainty
> >> interpreted as a polygon, as an engineer would, but
> >> rather simply as a magnitude of uncertainty.
> >
> > Partly right.  Because the uncertainty is not a precise
polygon;
> > it is a lack of additional precision.  It is an uncertanty
of
> > the number of digits of precision by the sender, and an
EXACT
> > transfer of that same uncertany to the recepient. In that
sense
> > it conveys the "magnitude of uncertainty" from the sender to
the
> > recepient in an exact format that cannot be missinterpreted.
> >
> >> The problem is that this representation does
> >> not fit the reality.
> >
> > It may not fit with the reality of some APRS implementations
> > that took the simplistic approach of truncating digits, but
it
> > does transfer exactly from the sender to the receiver the
> > knowledge of the ambiguity if displayed properly.  If one
> > doesn't have a digit of precision, then he should NOT stick
in a
> > ZERO.  Stick in a SPACE character, just like he would write
it
> > on a piece of paper.
> >
> >> So, think of ambiguity as representing a circle,
> >> taking the center of the polygon described by the
> >> lowest and highest values of the missing digits,
> >> and with the radius of the magnitude of the missing
> >> digits.
> >
> > Yes, now we are talking about how to display it.  This now
is
> > why it is so important to do it consistently across all APRS
> > clients so that everyone gets the same visualization that
the
> > sender intended...
> >
> > What you describe above is what I intended for display but
with
> > one additional tweak as implemented in APRSdos.  And that is
to
> > provide a SLIGHT random offset within that area of
uncertanty so
> > that if multiple APRS positions are reported in that same
area,
> > that they are not all stacked on top of each other so that
only
> > the top one appears.
> >
> > If they all use the same precise center of the area, then
only
> > the latest ICON shows on the map and only one CIRCLE of
> > ambiguity shows.  This can be very missleading to the casual
> > viewer of the map.  But in APRSdos, if there are 6 such
stations
> > reporting ambiguity in the same polygon, then each of their
> > circles of ambiguity will each show, but slightly offset so
that
> > they all individually appear and so at a glance, one can see
> > that there are 6 stations there.
> >
> > It is very simple.  This is the definition of APRS
ambiguity:
> >
> > 1) The APRS position field is a CHARACTER string
> > 2) The sender only includes the digits he knows
> > 3) On receipt a circle of ambiguity is displayed that
represents
> > the possible ambiguity due to the lack of precision
> > 4) For display purposes, thse circles are offset slightly so
> > that multiple stations reporting the same ambiguous position
do
> > not all appear as a single display.
> >
> > In addition, the original APRSdos does the following:
> >
> > A) The SYMBOL is only shown as long as the size of the
symbol
> > overlaps the size of the circle. In this case the circle is
> > hidden or not displayed.  Example, viewing a .1 mile
ambiguous
> > station on a 100 mile map scale, you see the symbol and all
> > looks normal.
> >
> > B) As one zooms in, and the circle becomes larger than the
> > symbol, then the SYMBOL disappears and only the circle is
> > displayed.  This avoids the appearance of the symbol as an
> > "exact location inside a circle".  It is not.  At this
point,
> > the circle is the best representation for that station, the
> > symbol is not.
> >
> > C) Originally, APRSdos simply let the SIZE of the symbol
expand
> > so that it always covered the area of ambiguiy as the map
was
> > zoomed.  But this can clutter the map.  My favorite example,
is
> > when I arrive in a city airport and I enter the estimated
> > position of the city into my HT with a 10 mile ambiguity
just to
> > show where I am (without carrying a GPS).  I do not want my
> > SYMBOL to cover the entire city!
> >
> > So that is why I fell back to (B) above as the best way to
> > convey the ambiguity to the recepient at high map zooms.
> >
> > Bob, WB4APR
> >
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> >
> >
> 
> 