[aprssig] RE: Position Ambituity in APRS!

[Richard Amirault]

This message not read because the poster apparently quoted an *entire* 
digest before leaving his comments at the bottom.

Richard Amirault
Boston, MA, USA
http://n1jdu.org
http://bostonfandom.org
http://www.youtube.com/watch?v=J7hf9u2ZdlQ
----- Original Message ----- 
From: "Alex Carver" <kf4lvz at yahoo.com>
To: <aprssig at lists.tapr.org>
Sent: Wednesday, January 09, 2008 1:23 PM
Subject: [aprssig] RE: Position Ambituity in APRS!


>
> --- aprssig-request at lists.tapr.org wrote:
>
>> Send aprssig mailing list submissions to
>> aprssig at lists.tapr.org
>>
>> To subscribe or unsubscribe via the World Wide Web,
>> visit
>>
>>
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>> or, via email, send a message with subject or body
>> 'help' to
>> aprssig-request at lists.tapr.org
>>
>> You can reach the person managing the list at
>> aprssig-owner at lists.tapr.org
>>
>> When replying, please edit your Subject line so it
>> is more specific
>> than "Re: Contents of aprssig digest..."
>>
>>
>> Today's Topics:
>>
>>    1. RE: Position Ambituity in APRS! (Robert
>> Bruninga)
>>    2. Mic-E Position Ambituity in APRS (Robert (Alex
>> Carver)
>>    3. RE: Position Ambituity in APRS! (Robert
>> Bruninga)
>>    4. RE: Position Ambituity in APRS! (Robert
>> Bruninga)
>>    5. RE: Position Ambituity in APRS! (Robert
>> Bruninga)
>>    6. RE: Position Ambituity in APRS! (Robert
>> Bruninga)
>>    7. RE: Position Ambituity in APRS! (Robert
>> Bruninga)
>>    8. Ambiguity background (Robert Bruninga)
>>    9. RE: Mic-E Position Ambituity in APRS (Robert
>> (Robert Bruninga)
>>   10. Re: Position Ambituity in APRS! (J. Lance
>> Cotton)
>>   11. Clarification of Ambiguity in APRS (Robert
>> Bruninga)
>>   12. RE: Position Ambituity in APRS! (Andrew Rich)
>>   13. RE: Position Ambituity in APRS! (William
>> McKeehan)
>>   14. Voice Repeater object for digis (Robert
>> Bruninga)
>>   15. Re: aprssig Digest, Vol 43, Issue 8 (Rodney
>> Baker)
>>   16. Re: Voice Repeater object for digis (Joel
>> Maslak)
>>   17. RE: Voice Repeater object for digis (Robert
>> Bruninga)
>>   18. 2008 Worldwide New-N APRS Digipeater
>> statistics Update
>>       (Robert Bruninga)
>>   19. RE: Voice Repeater object for digis (Robert
>> Bruninga)
>>   20. RE: Position Ambituity in APRS! (Robert
>> Bruninga)
>>   21. RE: Position Ambituity in APRS! (William
>> McKeehan)
>>   22. RE: Position Ambituity in APRS! (William
>> McKeehan)
>>   23. RE: Position Ambituity in APRS! (Robert
>> Bruninga)
>>
>>
>>
> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 8 Jan 2008 13:11:53 -0500
>> From: "Robert Bruninga" <bruninga at usna.edu>
>> Subject: RE: [aprssig] Position Ambituity in APRS!
>> To: "'TAPR APRS Mailing List'"
>> <aprssig at lists.tapr.org>
>> Message-ID:
>> <044e01c85221$f257ae10$42577a83 at ewlab.usna.edu>
>> Content-Type: text/plain; charset="US-ASCII"
>>
>> >> 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.  This would have made very good sense
>> > in the protocol.
>>
>> It is EXACTLY how APRSdos did it originally, but
>> remember in
>> putting together the APRS SPEC, the follow-on
>> authors refused to
>> allow ANYHING in the spec to tell them HOW to
>> display anything
>> in APRS.
>>
>> This was the fiercest battle.  I wanted the APRS
>> spec to promote
>> COMMON display techingues for the same data to avoid
>> these kinds
>> of end user confusion.  All other authors insisted
>> on no RECEIVE
>> or DISPLAY standards  so they could display things
>> anyway they
>> wanted.  I was on record as adamantly opposed to
>> this kind of
>> tower of Babble in APRS.
>>
>> But the only way to get a spec out was to agree to
>> the lowest
>> common denominator and that was only what is
>> TRANSMITTED.
>> Therefore the spec (except where I could sneak it
>> in) has very
>> little to do with reception.  That is why different
>> users of
>> different clients now see quite different things...
>> This is one
>> of my biggest frustrations with the state of APRS
>> today.
>>
>> Oh well.  Spilt milk..
>>
>> > Perhaps with with the addition of random
>> > placement of the center for those people
>> > that actually have an accurate positional
>> > sensor but don't want to convey their exact
>> > location.  Kill two birds with one stone.
>>
>> Yep, That is what APRSdos does and what I wanted all
>> along for
>> all displays.  I just wish all authors would
>> implement it that
>> way or something similar.
>> The Xastir approach is similar and quite acceptible.
>>
>> But the important thing is to at least display
>> ambiguity
>> unequivocably to the user.  There are still many
>> applications
>> that ignore position ambiguity and plot it precisely
>> no matter
>> how imprecise it is.
>>
>> That is bad for APRS integrity.
>>
>> Bob, WB4APR
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 8 Jan 2008 10:18:19 -0800 (PST)
>> From: Alex Carver <kf4lvz at yahoo.com>
>> Subject: [aprssig] Mic-E Position Ambituity in APRS
>> (Robert
>> To: aprssig at lists.tapr.org
>> Message-ID:
>> <142375.50017.qm at web50410.mail.re2.yahoo.com>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>>
>> -
>> >
>> > Message: 11
>> > Date: Tue, 8 Jan 2008 12:53:41 -0500
>> > From: "Robert Bruninga" <bruninga at usna.edu>
>> > Subject: [aprssig] Mic-E Position Ambituity in
>> APRS
>> > To: "'TAPR APRS Mailing List'"
>> > <aprssig at lists.tapr.org>
>> > Message-ID:
>> > <043f01c8521f$678c4950$42577a83 at ewlab.usna.edu>
>> > Content-Type: text/plain; charset="US-ASCII"
>> >
>> > > I have a D700.  What does *it* do to
>> > > the GPS Lat/Lon data when Pos-ambig is
>> > > turned on?
>> >
>> > In the normal APRS format.  Unavailable digits of
>> > precision are
>> > replaced with a SPACE.
>> >
>> > In the D700 (Mic-E format), unavailable digits of
>> > precision in
>> > the latitude are replaced with the letter "Z" (not
>> > zeros).  The
>> > Longitude then is assumed to have the same level
>> of
>> > precision.
>> >
>> > When a person enters his estimated position into a
>> > D7 or D700
>> > manually, he only enters those digits he knows.
>> > Then he uses
>> > the position ambiguity menu to INDICATE how many
>> > extra digits of
>> > precision he is not using.  The result is exactly
>> > the same.
>> >
>> > On decoding of the Mic-E format, the position used
>> > by the client
>> > program should not insert "0's" into those unused
>> > positions, but
>> > SPACES just like the full APRS format does.
>> Again,
>> > this is not
>> > truncation, but reproducing at the receipent
>> exactly
>> > what the
>> > sender intended.
>> >
>>
>> Sorry, Bob, but what you describe is precisely the
>> definition of truncation.  If I truncate something,
>> I
>> lop off a piece of it and leave nothing behind.  The
>> value "34.4567" truncated to two decimal places is
>> "34.45__".  Rounding is a different story since I
>> may
>> change one of the digits.  But pure truncation is
>> exactly what you've done.
>>
>> The application is going to insert not just zeros
>> but
>> a whole range of values to plot the result.
>>
>> If I've got "34.45__" then the full range of values
>> between 34.4500 to 34.4599 when truncated result in
>> the value you just transmitted.  So the application
>> should rightly plot a line from 34.4500 to 34.4599.
>> This should happen for latitude and longitude.  Two
>> perpendicular lines are now generated, sweeping
>> through a range of values on the surface of a sphere
>> results in a spherical trapezoid (a degenerate
>> spherical trapezoid at the poles which is a
>> spherical triangle).
>>
>>
>>
>>
> ____________________________________________________________________________________
>> Looking for last minute shopping deals?
>> Find them fast with Yahoo! Search.
>>
> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 8 Jan 2008 13:19:24 -0500
>> From: "Robert Bruninga" <bruninga at usna.edu>
>> Subject: RE: [aprssig] Position Ambituity in APRS!
>> To: "'TAPR APRS Mailing List'"
>> <aprssig at lists.tapr.org>
>> Message-ID:
>> <044f01c85222$ff86f720$42577a83 at ewlab.usna.edu>
>> Content-Type: text/plain; charset="US-ASCII"
>>
>> > The APRS spec is of course the overriding
>> > authority here.  It specifies truncation
>> > of lat/long least significant digits as the
>> > means of conveying ambiguity.
>>
>> Unfortunately, This is the incorrect interpretation
>> that
>> continues to propogate.  But it is simply wrong.
>>
>> The spec does not say anything about truncation.  It
>> says that
>> if less than the full DEG, MIN and decimal
>> hundredths of minutes
>> of precision are available, then those unavailable
>> digits are
>> transmitted as SPACES.
>>
>> This is not truncation.  It is transmitting to the
>> receiver only
>> the information available to the sender.  I felt
>> very strongly
>> about this, so that people would not insert zeros as
>> fillers.
>> Yet, unfortunately, that is exactly what happens in
>> many
>> implementations.
>>
>> Bob, WB4aPR
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 8 Jan 2008 13:24:06 -0500
>> From: "Robert Bruninga" <bruninga at usna.edu>
>> Subject: RE: [aprssig] Position Ambituity in APRS!
>> To: "'TAPR APRS Mailing List'"
>> <aprssig at lists.tapr.org>
>> Message-ID:
>> <045301c85223$a79a2810$42577a83 at ewlab.usna.edu>
>> Content-Type: text/plain; charset="US-ASCII"
>>
>> I still don't like polygons.  These Boxes drawn
>> exactly on a
>> LAT/LONG grid imply a precise boundary of ambiguity
>> which is
>> totally missleading and of drastically differrent
>> sizes from the
>> eauator to the poles.  They just convey the wrong
>> information
>> completely.
>>
>> I like the original APRSdos circles whos radius
>> approximates the
>> degree of ambiguity.  This completely eliminates any
>> distortion
>> no matter where on the planet they occur.
>>
>> Bob WB4APR
>>
>>
>> > -----Original Message-----
>> > From: aprssig-bounces at lists.tapr.org
>> > [mailto:aprssig-bounces at lists.tapr.org] On Behalf
>> Of Curt,
>> WE7U
>> > Sent: Tuesday, January 08, 2008 12:17 PM
>> > To: TAPR APRS Mailing List
>> > Subject: Re: [aprssig] Position Ambituity in APRS!
>> >
>> > On Tue, 8 Jan 2008, Steve Dimse wrote:
>> >
>> > > You do not have the ability to place the
>> > > center anywhere you want, just in the center of
>> pre-defined
>> > polygons,
>> > > with predetermined radii. (And sorry Curt, my
>> extreme
>> nitpicking
>> > > suggests the linear projection of these polygons
>> is never a
>> > rectangle.
>> > > For ambiguities that do not cross the poles or
>> equator (the
>> > only case
>> > > allowed by the protocol), the border away from
>> the equator
>> > is shorter
>> > > than border towards the equator, making it a
>> trapezoid.
>> Though they
>> > > can't be represented by the APRS implementation,
>> ambiguities
>> that
>> > > cross the equator would be hexagons, and the
>> interesting
>> > polar case is
>> > > left as an exercise for the reader!)
>> >
>> > Saw your correction right after this calling them
>> a trapezoid.
>> > Trapezoids are correct - For some projections.
>> They'd be
>> trapezoids
>> > with slightly curved sides (which I'm sure goes
>> against the
>> > _mathematical_ definition of trapezoids, but who
>> cares!).
>> >
>> > For unprojected lat/long, they're rectangles, even
>> at the
>> polar
>> > regiions (weird huh?).  Not that any of this
>> matters much to
>> the
>> > current discussion about ambiguity.  hi hi
>> >
>> > --
>> > Curt, WE7U: <www.eskimo.com/~archer/>     XASTIR:
>> <www.xastir.org>
>> >   "Lotto:  A tax on people who are bad at math."
>> -- unknown
>> > "Windows:  Microsoft's tax on computer
>> illiterates." -- WE7U
>> > The world DOES revolve around me:  I picked the
>> coordinate
>> system!
>> >
>> > _______________________________________________
>> > aprssig mailing list
>> > aprssig at lists.tapr.org
>> >
>>
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>> >
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Tue, 8 Jan 2008 13:44:03 -0500
>> From: "Robert Bruninga" <bruninga at usna.edu>
>> Subject: RE: [aprssig] Position Ambituity in APRS!
>> To: "'TAPR APRS Mailing List'"
>> <aprssig at lists.tapr.org>
>> Message-ID:
>> <045d01c85226$70dfa900$42577a83 at ewlab.usna.edu>
>> Content-Type: text/plain; charset="US-ASCII"
>>
>> > Bob shows this by drawing a 60 mile radius
>> > around 35.5/83.5. An engineer would display
>> > this as a polygon 60 miles  LARGER than the
>> > polygon 35-36 by 83-84,
>>
>> Which would be pretty silly wouldn't it...
>>
>> Nit pickers note:
>>
>> If you go back all the way through the last 10 years
>> of this
>> debate, I have always referred to these degrees of
>> precision as
>> 60 mile, 10 mile, 1 mile and .1 mile ambiguity
>> (nautical miles).
>> Because this is exactly what they are.  In Latitude,
>> this
>> applies everywhere on earth from the equator to the
>> poles.
>>
>> This was always interpreted in the original APRSdos
>> as a 60, 10,
>> 1 and 0.1 mile circles of ambiguity.  That is how I
>> intended for
>> them to be drawn. The spec does not fully convey
>> this background
>> and gives the reader the incorrect interpretation in
>> this
>> sentence: "The station may be located anywhere in a
>> bounding
>> box..."
>>
>> I wish I had caught the potential error of that
>> sentence 10
>> years ago.  But I was working extra long hours
>> building a
>> satellite while an independent technical editor was
>> trying to
>> get APRS down into a spec.  It was clear how APRSdos
>> displayed
>> this as circles at the time, and so I trusted he
>> would properly
>> capture the escence of that system into the spec.
>>
>> But since I was not allowed to include any
>> descriptions of how
>> things were to be displayed on receipt, my
>> recommendations in
>> this paragraph were omitted.
>>
>> > but then again an engineer would have designed
>> > the protocol to send a precise best guess along
>> > with an uncertainty value, so the display
>> > actually meant something.
>>
>> The engineer refused to misslead all viewers by
>> sending a
>> "precise best guess" when PRECISION was not
>> avaialble.  Instead
>> the engineer designed APRS to send the same lack of
>> precision
>> from the sender to the receiver so that there could
>> be no
>> mistake in interpretation.
>>
>> Bob, WB4APR
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Tue, 8 Jan 2008 13:53:27 -0500
>> From: "Robert Bruninga" <bruninga at usna.edu>
>> Subject: RE: [aprssig] Position Ambituity in APRS!
>> To: "'TAPR APRS Mailing List'"
>> <aprssig at lists.tapr.org>
>> Message-ID:
>> <046401c85227$c13f4350$42577a83 at ewlab.usna.edu>
>> Content-Type: text/plain; charset="US-ASCII"
>>
>> > yeah, those jokers stuck to the spec. Rev G of the
>> spec says:
>> >
>> > "Where the exact position is not known, the mm
>> > and hh digits in the latitude and longitude may
>> > be progressively replaced by a V (space) character
>>
>> > as the amount of imprecision increases."
>>
>> Exactly.  And since a Degree of latitude is 60 miles
>> and a
>> minute of latitude is 1 mile, then the degree of
>> ambiguity
>> conveyed for these four cases is 60, 10, 1 and 0.1
>> nautical
>> mile.
>>
>> > a rectangle due to the nature of the coordinate
>> > system in use.  It's nowhere close to a circle.
>>
>> Sorry, it is a circle in the original APRSdos and
>> any other map
>> projection that does not have the simplistic
>> mercator projection
>> distortions.  A mile is a mile no matter where you
>> are on the
>> earth.  And ambiguity was intended to imply those
>> circles.
>>
>> I agree that the wording of the spec can be
>> interpreted as a box
>> of LAT/Long with different sizes all over the earth,
>> but that
>> interpretation would be a poor choice for a
>> standard.  Hence I
>> have always tried to make everyone understand that
>> these were
>> always intended to be circles of ambiguity relative
>> to the
>> number of digits of precision available in the
>> latitude.
>>
>> Bob, WB4APR
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Tue, 8 Jan 2008 14:04:22 -0500
>> From: "Robert Bruninga" <bruninga at usna.edu>
>> Subject: RE: [aprssig] Position Ambituity in APRS!
>> To: "'TAPR APRS Mailing List'"
>> <aprssig at lists.tapr.org>
>> Message-ID:
>> <046801c85229$476aaf90$42577a83 at ewlab.usna.edu>
>> Content-Type: text/plain; charset="US-ASCII"
>>
>> > 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.
>>
>> Message: 9
>> Date: Tue, 8 Jan 2008 14:16:58 -0500
>> From: "Robert Bruninga" <bruninga at usna.edu>
>> Subject: RE: [aprssig] Mic-E Position Ambituity in
>> APRS (Robert
>> To: "'TAPR APRS Mailing List'"
>> <aprssig at lists.tapr.org>
>> Message-ID:
>> <046d01c8522b$09db0880$42577a83 at ewlab.usna.edu>
>> Content-Type: text/plain; charset="US-ASCII"
>>
>> > Sorry, Bob, but what you describe is precisely
>> > the definition of truncation.  If I truncate
>> > something, I lop off a piece of it and leave
>> > nothing behind.
>>
>> Wrong interpretation.  You have nothing to truncate
>> or to lop
>> off.  If you only know a position as 3859 and no
>> further
>> precision, then you are not lopping off anything.
>> You are only
>> transmitting what you have.
>
> But if I know all my digits and choose to follow YOUR
> specification of only transmitting the first few
> digits to obfuscate my position, then that IS
> truncation.
>
>
>> > The value "34.4567" truncated to two decimal
>> > places is "34.45__".  Rounding is a different
>> > story since I may change one of the digits.
>> > But pure truncation is exactly what you've done.
>>
>> No way.  If I had a position of 34.4567, then I
>> would transmit
>> it.  There is nothing to truncate because there is
>> nothing
>> missing.
>
> There is information missing if I don't transmit it.
> I am the transmitter, I can choose (up to the limit of
> what I know) how much information to transmit.  If I
> have 20 decimal places of real accuracy and I choose
> to send one place, then by YOUR specification I must
> put spaces in the rest of the digits.  That's
> truncation again.
>
>>
>> > The application is going to insert not just zeros
>> but
>> > a whole range of values to plot the result.
>>
>> It should not insert or present precision that was
>> not know by
>> the sender.
>>
>> > If I've got "34.45__" then the full range
>> > of values between 34.4500 to 34.4599 when
>> > truncated result in the value you just
>> > transmitted.
>>
>> No you do not.  You do not have those range of
>> values.  You only
>> have what the sender sent.  That is "34.45"  to
>> suggest that is
>> the same as 34.4500 would fail middle school
>> science.
>
> Right, I have what the sender sent.  To have an idea
> of where he might be, he's anywhere along that line.
> What I do not know was the sender's INTENT!  I don't
> know if the sender didn't know his position or didn't
> want to give it away.  All I know is he sent two
> decimal places of accuracy.  So I'm stuck having to
> guess (or randomize in your parlance) his position
> which means anywhere along that line from 34.4500 to
> 34.4599.
>
>
> Plus, if you look at the message down the line that
> quotes the Kenwood manual, they truncate, too.
>
> The specification is broken as is.  As it is written,
> it specifies truncation as the method to accomplish
> the transmission of position ambiguity regardless of
> the source of that ambiguity:  willful or consequence
> of the situation.  Your specification can't tell the
> difference.  It can't transmit the sender's intent for
> the ambiguity and leaves us having to use ranges to
> approximate a location.  Since, as it is written, it
> uses truncation, we're left with our existing
> interpretation of a box not a circle.
>
>
>
> 
> ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search. 
> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig