[aprssig] spaces in object names

[Steve Dimse]

On Aug 13, 2009, at 8:57 AM, Pete Loveall AE5PL Lists wrote:

>> -----Original Message-----
>> From: Steve Dimse
>> Sent: Thursday, August 13, 2009 7:40 AM
>>>
>>> Because the trailing spaces are irrelevant.
>>
>> Nowhere in the spec does it say that. It was assumed, but as Pete
>> pointed out, when we were discussing trailing spaces he said all nine
>> characters are significant, and that I "misinterpreted" that to mean
>> the trailing spaces were significant. Semantics, I don't understand
>> how all nine characters are significant yet you can ignore trailing
>> spaces, but now that Pete has clarified what he meant I can move on.
>
> Steve, quit misquoting me.  I said your -assumption- that I was  
> talking about what I do on jFindu is incorrect.  Nowhere did I say  
> that trailing spaces are insignificant.  If you store Objects  
> separately and display them separately, all 9 characters are  
> significant in Object names according to the spec.  What we as  
> authors have done (as stated multiple times before) is to  
> incorrectly combine Object names and station callsign-SSIDs either  
> in our databases or on our displays or both such that they are  
> indistinguishable and that is what introduced the ambiguity.  I wish  
> you would quit misquoting me or making statements about what I meant  
> when you obviously have no idea what I said or meant.

I can assure you, any misquote is accidental. Even reading what you  
wrote above I'm confused. So I do not keep getting it wrong, does  
jfindu treat "K4HG" and "K4HG     " the same or not?
>
>>> Remember that the object name
>>> is fixed length 9 caracters, with space fillers. This means that
>>> there is
>>> no object name beeing transmitted as "VE2PRT"  or "VE2PRT  "; they
>>> both
>>> are transmitted as "VE2PRT   " (with exactly 3 spaces at the end).
>>
>> No, but there are item names being transmitted with 1 to 7 characters
>> (trailing spaces not required but not prohibited), and there are real
>> stations being transmitted without trailing spaces. That is the  
>> issue.
>
> And, as I also stated in an earlier post, Items complicate the mix  
> even more.  But that still does not say that the spec is incorrect  
> or that we should begin adding unrelated restrictions because one  
> person or another finds their display ambiguous.  What we as  
> database designers should do is revisit our databases and separate  
> Objects from station from Items and then present them as obviously  
> different entities (I am considering how to do that with javAPRS  
> right now.  The jFindu database is a much simpler issue to correct.).

Separating objects, items, and objects is not the way APRS needs to be  
to support tactical communications. They need to treated the same.  
Please consider the way people use APRS, not the way your computer  
science logic says it should be done. Database designers should  
SUPPORT the use of the system, not be dictate its use because a  
computer science principle says it should be a certain way.
>
> So what we agree on is that as currently displayed on APRS clients  
> and web sites, it is very difficult to distinguish between stations,  
> Objects, and Items, both in the client databases and in the client  
> displays (clients=PC applications, web applications, etc.).

They should not be distiguishable AT ALL!


Steve K4HG