| |
ZL3AI > APRDIG 17.11.03 11:46l 281 Lines 11251 Bytes #999 (0) @ WW
BID : 2293-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 06, 2/5
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<IK1ZNW<GB7CRV<GB7CIP<
GB7COV<GB7BHM<ZL2BAU<ZL3VML
Sent: 031117/0851Z @:ZL3VML.#80.NZL.OC #:13003 [Chch-NZ] FBB7.00i $:2293-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 6 Nov 2003 08:55:53 -0800
X-Message-Number: 8
Position ambiguity is a useful feature. OpenTrac provides an element for
it, as well as for reported GPS parameters. I DON'T like the scheme for
gating DX spots, though. IMHO, it's worse than useless. If you can look up
grid squares in QRZ and plot stations as objects in such a way that they can
be distinguished from 'real' stations, and can be filtered out, fine. For
non-mobile users that's probably a useful feature. But assigning locations
to calls based on region numbers? And putting everyone from one region in
the same 1 degree square? That's pointless. I've got a region 1 call, and
I live in 6 land. My parents still have their 6 calls, and live in
Virginia, roughly 3000 miles away. Even in California, you're going to be
off by hundreds of miles for most people.
Even worse than posting such bogus data is the fact that there's no way for
the average user to KNOW that it's bogus. If you're going to assign a
position to something, you'd better have a good idea that it's actually at
that position.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: SSID Conventions?
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 6 Nov 2003 08:59:55 -0800
X-Message-Number: 9
Does ANYONE need this anymore? What tracker can't put a symbol character in
a message?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: SSID Conventions?
From: "Matt Werner" <kb0kqa@arrl.net>
Date: Thu, 6 Nov 2003 11:52:52 -0600
X-Message-Number: 10
What about a TNC with a GPS connected directly (such as a KPC-3)? Although I
only used one for a very limited time, can you specify the symbol if you are
sending out something like a GPRMC sentence?
73 - Matt
>Does ANYONE need this anymore? What tracker can't put a symbol character in
>a message?
>
>Scott
>N1VG
----------------------------------------------------------------------
Subject: Re: SSID Conventions?
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 6 Nov 2003 09:58:21 -0800
X-Message-Number: 11
Isn't that why we have the GPxxxx TOCALLs?
----- Original Message -----
From: "Matt Werner" <kb0kqa@arrl.net>
To: <scott@opentrac.org>
Cc: <aprssig@lists.tapr.org>
Sent: Thursday, November 06, 2003 9:52 AM
Subject: Re: [aprssig] Re: SSID Conventions?
>What about a TNC with a GPS connected directly (such as a KPC-3)? Although I
>only used one for a very limited time, can you specify the symbol if you are
>sending out something like a GPRMC sentence?
>
>73 - Matt
----------------------------------------------------------------------
Subject: Re: [ Scott Miller ] Re: SSID Conventions?
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Thu, 06 Nov 2003 12:07:12 -0600
X-Message-Number: 12
>Isn't that why we have the GPxxxx TOCALLs?
Yes.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 6 Nov 2003 13:34:48 -0500
X-Message-Number: 13
On 11/6/03 at 10:48 AM Phil Pacier, AD6NH <ad6nh@arrl.net> sent:
>Perhaps one solution (after all these bugs are dealt with) for the DX
>cluster objects is to create another parallel network, such as been done
>for APRS FIRENET.
They already have one, at least as old as the APRS Internet System.
Understand what is going on here...this is nothing to do with the DX
spotting network...it is a single ham, who has written code to take DX
spots and convert them to APRS objects. It is a situation analagous to the
various weather gateways, earthquake gateways, and so on, conversion of
data from one source to APRS format.
These reports are sent as regular APRS objects, with no ambiguity. Among
other evils, an APRS user that is "spotted" on the European DX network will
suddenly have his position jump to whatever location has been chosen for
his prefix.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: SSID Conventions?
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 6 Nov 2003 13:37:26 -0500
X-Message-Number: 14
On 11/6/03 at 8:17 AM Scott Miller <scott@opentrac.org> sent:
>I've seen this before, and I still can't help thinking that it's totally
>pointless. I've got more than one station, so I have to choose one of the
>other SSIDs. Yet all of the non-zero SSIDs have other meaning attached to
>them - meaning that's completely duplicated in the symbol system. More
>importantly, there's no way to indicate that the SSID is significant, so
>even if you do have a tracker on an ambulance, how do you tell that apart
>from hundreds of other -1 stations that AREN'T ambulances? Is there
>something I'm missing here?
No, you are not. The use of ssid to infer a symbol is deprecated, there is
never a situation where a symbol cannot be self-assigned. This is one of
those old remnats of early APRS, and as long as you are sending a symbol,
you can use any SSID for any type of station.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 6 Nov 2003 10:59:54 -0800
X-Message-Number: 15
>These reports are sent as regular APRS objects, with no ambiguity. Among
other
>evils, an APRS user that is "spotted" on the European DX network will
suddenly
>have his position jump to whatever location has been chosen for his
prefix.
Very, very bad, to the point of bordering on malicious interference IMHO.
Has anyone spoken to the person doing the gating? This is a perfectly valid
application of APRS technology, but NOT something that should be on the
primary APRS-IS!
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 6 Nov 2003 14:06:29 -0500
X-Message-Number: 16
On 11/6/03 at 10:27 AM Gregg G. Wonderly <gregg@skymaster.cytetech.com> sent:
>>I do understand this is the way you set up APRSdos, but to developers and
>users
>>of other systems, it makes no sense. In a windowing environment, it makes much
>>more sense to be able to point at an object and get all the details, rather
>than
>>to try to convey a few of bits of information with color. Monochrome icons
>>(excuse me, symbols) just won't fly in a windowed environment. There is a
>reason
>>no other APRS program implements your color symbol plan, and I think you need
>to
>>accept that.
>
>Steve, I don't think that you can speak for all developers with this kind of
>snotty nosed expert talk. I think that this kind of carrying on about your
>opinion regarding Bob's design is what continues to fragment the software that
>tries to support APRS from being what it really could be.
Personal attacks resume. Be nice just once to have a discussion on the sig
without name-calling.
I stand behind my statement. As Bob admits, no one else has implemented his
color scheme to display those three bits of information. The question is
why!
It certainly is not out of ignorance. Bob has been pushing this since
MacAPRS came out nearly 10 years ago, and early GUI APRS developers like
the Sprouls, myself, and Brent all were APRSdos users first, if for no
other reason than there was no other choice.
I maintain it is because this is simply not useful to most users, who would
rather have symbols that are easy to identify (and yes, even pretty) than
to have three bits of information conveyed by symbol color.
>It appears that many of the APRS software packages have failed to carry all of
>the facets around and use them effectively.
Not everything needs to be done as Bob does. In fact this is a wonderful
thing, I wouldn't want to be using APRSdos for Macintosh. APRS has
benefited greatly from the freedom to do things differrently than Bob.
What is needed is certain commonality. For example, whether a station can
accept messages is something that does need to be passed on to the user. It
is fine to require that that information be made available to the user.
However, to dictate that it must be made through the color of the symbol is
counter-productive in my opinion.
In dos (at least as of the date I last used APRSdos), you cannot just click
on a symbol, and have a new window pop-up. The process of "hooking" an
object means using the cursor to get there, awkward at best. On the other
hand, in Mac and other windowing environments, this is a normal action. So,
if I need to know if station can accept a message, it is trivial to double
click on the station and bring up a window, cntaining this (and tons of
other information).
Furthermore, in javAPRS (and in findU for that matter), you never had the
ability to send a message to a station anyway, so why should I be forced to
place this information on my display???
>There is no reason that the
>rendering can not happen as Bob suggests in any 'windowing' environment. The
>software development environments that many packages use may make it easier to
>use an Icon. I've used VC++, and the drawing libraries are very tedious.
>But, that does not, make it impossible to draw multi-faceted symbols.
>
>Java makes it much easier...
I never claimed you couldn't do it, or that any particular language made it
difficult. Fact is, any programming language and windowing environment can
do it. What I was claiming was that it wasn't done because it didn't make
sense to the developers of the programs, and further wasn't demanded by
their users. There is a big difference here!
Another Bob UI crusade was the presence of a power-of-two scale on the map.
He wanted to be sure that anyone looking at the 64 mile scale was seeing
the same thing. On findU I couldn't do it because MapBlast used
power-of-five scales A bigger problem was, even if every client
implemented this, in a windowing environment it still doesn't fulfill Bob's
objective. My 17 inch Apple Powerbook has more than 4 times the pixels of a
VGA display, when I'm at the 64 mile scale, I'm seeing 4 times as much as
Bob. Should we therefore force each APRS map display to only be 640x480? .
I SAY NO! I maintain that there should be no limits on the UI, people
should be free to innovate and take advange of all that technology has to
offer!
>I can define popup menus trivially for each symbol, specific to the top of
>object it is and what facets it's carrying. I can use the built in drag and
>drop to relocate them, with 'drop' actions causing the new positions to be
>transmitted for object that I own.
Yes, you can, and that is nice idea. Problem is, this is exactly what Bob
is arguing AGAINST! Bob wants to take away your freedom to do this sort of
innovative design, instead just show the symbol with those 8 colors he
dictates to show those three bits of information! No pop up menus allowed!
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
