[aprssig] Position Ambituity in APRS!

Tue Jan 8 11:23:04 EST 2008

Let me jump in and ask a really simple question.

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?

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

-- 
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
>
>