[aprssig] spaces in object names

[Steve Dimse]

On Aug 13, 2009, at 6:22 AM, Pete Loveall AE5PL Lists wrote:

> I also find multiple underscores distasteful.  And multiple  
> periods.  And multiple commas.  And parenthesizes.  And braces.
>
> Now before everyone gets all up in arms, I am saying that A___N is  
> just as hard to visually distinguish from A____N as A   N is to  
> visually distinguish from A    N especially if they have any visual  
> distance separating them.  And most display make .... hard to  
> distinguish from ,,,, or ((( from {{{.

I do not like those others either, but I maintain that because of  
proportional fonts multiple spaces carry an especially poor  
readability. Furthermore, multiple embedded spaces are in use now,  
making it more important that these be addressed specifically. So far,  
the only reason I've heard expressed for this is essentially "that's  
the way DStar does it". We are not trying to to tell DStar what to do  
on their system, but rather what to do on APRS. Really, what they do  
is no different from AX-25, callsigns are a fixed length in AX-25, but  
when we print AX-25, the decades old convention is "K4HG-8" not  
"K4HG   -8". If they want to use space instead of dash, fine, I've  
given up trying to argue that. But why do they need to follow their  
space padding convention on APRS? If there is a reason I'm willing to  
listen, but if there is not, this only serves to increase the chances  
for confusion.

> IMO, what started this thread was someone taking to an extreme a  
> mistake that most all of us as software authors have done with  
> regards to Objects and Items.  The question originally posed  
> (privately but it has been brought up here already so I paraphrase  
> the original question here): "Is there a difference between 'AE5PL'  
> and 'AE5PL    '?"  The answer is "Yes" according to the spec (which  
> some have said we should not take so literally).  The problem is we  
> (myself included) as authors have -assumed- that we can consider  
> stations and Objects as being the same.  We display them the same.   
> We store them in the same tables.  We therefore equate Object names  
> to station callsigns.  In fact, IMO, this has been a great  
> disservice to the APRS community.  An APRS station is an -active-  
> transmitter (or APRS-IS client) that may have two-way communications  
> capability.  An Object is something created by an APRS station that  
> has no APRS communications capability and may (quite often)  
> represent non-amateur radio or at least non-APRS entities.  What we  
> as authors have done is blur this distinction by storing Objects in  
> the same tables as stations, keying on the Object name, and  
> displaying Objects in such a way as to be unable to discern the  
> mandatory 9 character length of an Object name.  This could have  
> been done by not trimming trailing spaces and displaying Objects  
> with enclosing quotes or any other enclosing delimiters.  But we  
> (all of us) were too smart for that and display and store Objects in  
> such a way as to force ambiguity.
>

It is not just a matter of programming. Part of the design of APRS is  
to be able to move other objects. Say you put a tracker in the lead  
vehicle of a marathon, and the tracker dies. You need to be able to  
take control of the symbol and move it manually in response to voice  
reports of the position of LEAD. Otherwise you end up with dead  
callsigns complicating tactical displays. "K4HG" and "K4HG    " need  
to be the same for the tactical use of APRS.
>
> BTW, what can make this more confusing is if we consider Objects and  
> Items as separate entities from stations in our display and storage,  
> then we also have to consider Objects and Items as separate entities  
> period because of the difference in naming requirements for the two  
> packet types.

All the more argument against treating them separately.

Steve K4HG