[aprssig] RE: Position Ambituity in APRS!
Alex Carver
kf4lvz at yahoo.com
Wed Jan 9 13:23:43 EST 2008
--- 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
More information about the aprssig
mailing list