[aprssig] Dead Reckoning in APRS

[VE7GDH]

Bob WB4APR wrote...

> I think the difference here is that you are only concerned with
> how you use APRS.  Whereas I am concerned with how everyone
> uses APRS and that everyone gets the tools they need to do
> the job...

That's a pretty fair assessment.

> Not at all!  And you nailed it on the head. It is my remaining
> mission in life to try to get rid of the "mis-communications"
> that we see in APRS everyday because of incomplete and
> inconsistent implementations that allow recepients to see
> something DIFFERENT than the sender intended!  The whole
> reason for having an APRS standard was to make sure these
> mis-communications do not occur.

Worthy goals! I'm not sure I agree about seeing something different than the
sender intended though. However, to move on... the APRS standard. I'm not
disagreeing that there are things in the spec that aren't implemented in all
APRS clients... e.g. no dead reckoning or allowance for entering an
ambiguous position in UI-View, but what do you see as "the solution" to what
you have in mind? Should everyone be running the same APRS client on their
computer as you? Should other APRS clients be banned or shunned? To me, the
only viable solution (if one is needed) is for an author or authors to step
up to the plate and write a program that does everything, satisfies
everyone's needs, runs on all hardware/operating system (within limits of
course), has all kinds of mapping options built in, can display weather
information, radar underlays, etc. and includes every single option that is
mentioned in the APRS spec and room to expand if and when changes to the
spec take place down the road. I'm sure that you know that I use UI-View and
I'm really happy with and would find it pretty tough to go back to static
maps or ones that showed no real detail. I haven't used APRSdos but do
realize that it has useful features built into it. No matter how well it
implements the APRS spec, I don't think you are going to get the whole world
to use that APRS client and none other.

If there are inconsistencies and things lacking in APRS clients then you and
others should be encouraging someone to write a program that does
everything. I haven't used Xastir. I wouldn't be too surprised if Xastir
users thought they were already well on the way to the perfect solution and
they might be. I just think there should be more tolerance on the SIG and
more understanding about what APRS is and where it is heading down the road.

> Yes, and it is my job to make sure that users are reminded
> of problems that are allowing users of some software not
> to see correctly the data transmitted by senders. We simply
> cannot sweep these inconsistencies in APRS under the
> rug. We need to address them and fix them. APRS is used
> in life and death situations, not just arm-chair internet
> gaming. When we uncover inconsistancies that cause
> mis-interpretation, we need to fix it or make everyone aware
> of the problem so they can work around it.

No arguments there as long as things are done in a constructive manner. I'm
sure you are aware that I have said it before, but p Programs like UI-View
aren't going to just go away. People are going to use them until there is a
compelling reason to move on. When they move on, I am pretty sure they are
going to want more features and not less, easier to use interfaces AND what
you see as things that you see as missing from those programs. Probably
better than 99% of APRS use is casual or arm-chair use like for vehicle
tracking on the daily commute, but as you say, it does a lot more than that
and it is used in life and death situations from time to time and it should
be robust enough that it stands a chance of passing the test when that
happens. When amateurs are helping out with a disaster, they should be doing
it with tools they know and use day-in and day-out so they are familiar with
them and don't have to spend time learning how to use them when the disaster
hits.

> So I am not trying to tell you how to use APRS, and you are
> welcome to use it they way you like. But I do take interest
> when I see inconsistancies and hope we can all work
> together to fix them.

I'm all for removing inconsistencies. I think if you threw a hundred APRS
users in a room (and you to keep them all on track!) and asked them how they
use it and what they would like to see done differently and what they would
like to see added, you would eventually come up with some answers. In the
end, it takes someone to implement those changes. This could possibly
involve changes in the spec (and changes in the way digipeaters operate),
but for the most part, would involve writing software that fully implements
the spec. I am happy with UI-View, but if Roger was still with us, I would
be at the top of the list in asking for subtle changes to be made to either
improve something or implement something that was left out. We all know that
development of UI-View itself ended with his passing, but UI-View just isn't
going to go away in a hurry because so many people use it and because others
are still willing to write add-ons to add some functionality. I know this
thread isn't completely about UI-View, but it is a big part of it.

PS - what does it take to get a new skier symbol added to the spec? It
should be the easiest thing to get changed. I still say there are more
skiers and winter travelers involved with APRS than there are tractors.
What if it was not the simple addition of an ASCII character in a chart
and a corresponding graphic to be used for the symbol and the distribution
of the new graphic? How can APRS advance if even a simple symbol addition
can't be done? I'm not asking for "blue RVs, red RVs and yellow RVs" but
if watching a station in a wilderness situation changed from arm-chair
observation to a SAR task, it could make quite a difference knowing if the
task involved a jogger, hiker, snowmobiler or a skier. Or if you needed
to request assistance from another wilderness traveler, it would be nice to
know if they were on skis or motorized transport. At least we can tell the
difference between a "bike" and a "motorcycle." Wouldn't want recepients
to see something DIFFERENT than the sender intended!

73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am!"