Order Tray | Contact Us | Home | SIG Lists

[aprssig] LAST WORD on Position Ambiguity.

Robert Bruninga bruninga at usna.edu
Fri Jan 11 16:47:38 UTC 2008


This is an attempt at a last word on Position Ambiguity.

In truth, Maybe I should not care HOW it is implemented as long
as it is implemented in all systems CONSISTENTLY!  What I want
in APRS is consistancy across all platforms.

I suppose that instead of defining it as we did originally,
(circle centered on the digits provided), we could equally
"define" it to be based on truncation.  The difference here is
that the center of the circle would always have to be offset to
the center of the "box".  While this violates elementary common
sense and rules of precision, I suppose I could support it if it
brought consistancy to APRS.  But it still must be a circle
representation of the stated 0.1, 1, 10 and 60 nmiles so that it
is the same everywhere on the planet.

So we need input on all systems to see which, do what, and what
a change would do:  We need a table.  Here is a start:

                                 APRSdos
TX Ambiguity:                    4 levels
TX process (round or truncate):  user entry
Display (circle or box):         circle
Center (digits or box):          digits
Randomised (yes no)              yes
Symbol (always, never, auto):    auto
Projection (mercator or scaled): scaled

When I say "box" I man a LAT/LONG polygon
When I way "scaled" for projection, this means that the map does
not blow up at high latitudes, but range circles remain circles!
(trivial to do by simply multiplying displayed longitude by
COS(lat) of the map center.

I will build a table with all the results, if I get good inputs.
If this table needs more categories to best describe the
capability for your software, then please tell me what to add to
it.  Then maybe we can standardize APRS and or fix those
programs that are poorly implemented.

Bob, WB4APR





> -----Original Message-----
> From: aprssig-bounces at lists.tapr.org 
> [mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Keith
VE7GDH
> Sent: Friday, January 11, 2008 12:58 AM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] RE: Position Ambituity in APRS!
> 
> Alex KF4LVZ wrote...
> 
> (this seems to have disappeared into the ether, so I'm sendng 
> it again)
> 
> > However, you didn't have to waste time quoting my entire
> > message either just to take a jab at me.
> 
> I know you know I didn't do that, but starting off the quoted 
> text with
> my name, callsign and email address visible was ambiguous 
> enough to make
> it look to someone not paying attention that you were talking 
> about me.
> 
> > If I were lost in the woods and I knew I was somewhere
> > between 35 and 36 degrees north and 85 and 86 west, I'll
> > transmit 35 N 85 N [WE KNOW YOU MEANT WEST]
> > and hope that the SAR people will search a box.
> 
> If to the best of your knowledge you were somewhere between 
> 35 and 36 N,
> and somewhere between 85 & 86 W, to me a more accurate
representation
> would be to send 35 30 N / 85 30 W with the appropriate spaces
for the
> ambiguity. Of course, if you just don't know you were 
> approximately half
> way between 35N and 36N and approximately half way between 
> 85W and 86W,
> it would be misleading. I can understand why ambiguity is
written into
> the spec, but it is very ambiguous!
> 
> To give another example, if you knew you were very nearly 35 
> N and very
> nearly 85W, would you still send 35N / 85W or would you enter
more
> digits... as many as you were reasonably confident about? I 
> don't think
> it should be a box. I think it should be a circle centred on
the
> position that to the best of the knowledge of the person
entering the
> coordinates is the correct position.
> 
> To me, an ambiguous position of 35N 85W means somewhere 
> between 34N and
> 36N and somewhere between 84W and 87W. My suggestion would be
to enter
> as many digits as you were confident about when entering your 
> position.
> 
> > So I end up dying in the wilderness and coming back to
> > haunt everyone.
> 
> Well, no. If you get lost in the wilderness and end up dying 
> there, it's
> your responsibility. If word gets through to SAR that you are
lost and
> in need of assistance, they will do their best to find you 
> and evacuate
> you to safety. If they don't find you because you couldn't
give them
> better directions, it's too bad. I feel sorry for you, but I 
> would feel
> sorrier for the burden that you (I know this is hypothetical) 
> placed on
> them by asking them to search for you. If you meet your 
> demise, you have
> gone to a better place... or not. Those that you asked to 
> search for you
> would have to deal with not being to save everyone they 
> looked for, but
> I digress. That's not really anything to do with APRS. As an
ex-SAR
> member, I thought that I would throw that in, but I just
wouldn't want
> you to come back and haunt me when it wasn't justified.
> 
> > Every other coordinate system on this planet uses
> > grids for uncertainty. The grid square system (it's
> > right there in the name, square), UTM, Maidenhead, all
> > of those are some kind of polygon not circles.
> 
> For the ground pounders, the UTM grid sure makes life a lot 
> easier. APRS
> of course uses degrees, minutes and decimal minutes. As soon 
> as you are
> working with other agencies, it's nice to know that it's as
easy as
> pushing a few buttons on a GPS to change the format.
> 
> > I would suggest as you modify the specifications...
> 
> Even though the APRS spec has been around a while, there are 
> probably a
> few things that should be re-worded. This is an opportunity 
> to hammer it
> out. Of course, I have never in my life been ambiguous about 
> a position.
> In the old days, I had a map and compass. These days I have a
map and
> compass AND a GPS receiver. Of course, with a GPS, I know 
> exactly where
> I am even if I am lost. If the batteries die, it still makes a
pretty
> good paper-weight to hold the map down if it's breezy.
> 
> When it comes down to it, ambiguity probably doesn't mean 
> much to a lot
> of people involved in APRS. It does to Bob because he probably
uses
> APRSDOS. I know from messages in the past that he is in the
habit of
> punching in an approximate lat/long at airports and while 
> hiking without
> a GPS. Both instances are examples of why ambiguity might
sometimes be
> used. To me - someone that has hardly ever gone anywhere
without a GPS
> (whether hiking, skiing, driving, on a SAR task or mountain
biking)
> since I got my first one - ambiguity doesn't make a lot of
sense.
> 
> For someone that is travelling without a GPS, it allows them
to
> participate in APRS e.g. with a D7. For someone with a D7 and
a failed
> GPS or one with dead batteries, it again makes sense. I 
> understand it. I
> would just never use it - unless experimenting!
> 
> When I say it doesn't mean much to a lot of people involved in
APRS, I
> am referring to the huge majority of APRS users that use
UI-View at
> home... and some on the road. It just doesn't display
ambiguity as Bob
> envisions it. It acts as if the spaces are filled zeroes.
Because the
> majority of people looking at your ambiguous position won't
know it's
> ambiguous unless they take a closer look at it, it would be to
your
> advantage - if you were like Alex in his example above - if 
> you were to
> use the "unknown position" symbol... \.  At least people 
> looking at you
> in a graphical environment will see that without even looking
for the
> missing digits, whether they are using UI-View or not.
> 
> I've been reading the discussion about ambiguity but not 
> paying a lot of
> attention to it. If I were to make any argument at all, it 
> would be that
> the ambiguous position would be represented by a circle and
not a box,
> with the diameter determined by the amount of ambiguity the
sender
> intended.
> 
> So... was any of the above ambiguous? hi
> 
> 73 es cul - Keith VE7GDH
> --
> "I may be lost, but I know exactly where I am!"
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 





More information about the aprssig mailing list