[aprssig] spaces in object names

[Patrick]

Not having a foothold on the battlefield, I would venture the  
suggestion that adding spaces in the middle of the field could be  
useful for tactical purposes.. It makes sense to me that trimming the  
text field should not affect the end user interaction with the data  
(such that "aaaa   " == "aaaa")....  Given a vote to the community, I  
would support spaces in the middle of the callsign/object string, with  
the understanding that they be understood to be handled by the client  
as trimmed strings.

That said, around the same effect can be duplicated by either an  
underscore or a period filling in the spaces as both do denote visible  
characters...

p

Quoting Bob Bruninga <bruninga at usna.edu>:

>
> Can we live with embedded spaces?
> (and ignoring trailing ones)
> APRSdos can... so I am open to the community conclusion...
>
> Bob, WB4APR
>
>
> ---- Original message ----
>> Date: Wed, 12 Aug 2009 18:01:29 -0500
>> From: aprssig-bounces at tapr.org (on behalf of Pete Loveall AE5PL  
>> Lists <hamlists at ametx.com>)
>> Subject: Re: [aprssig] spaces in object names
>> To: TAPR APRS Mailing List <aprssig at tapr.org>
>>
>>> -----Original Message-----
>>> From: Gregg Wonderly
>>> Sent: Wednesday, August 12, 2009 5:34 PM
>>>
>>> On an APRS display with proportional fonts, I believe Steve is saying
>>> that "K4HG
>>> A" and K4HG  A" are likely to be indistinguishable for many people.  I
>>> am not
>>> sure that this deserves such a heated battle unless there really is a
>>> good
>>> reason why a ' ' character is must have separator compared to some
>>> other
>>> delimiter such as '-'.
>>
>> There is a good reason which has been already mentioned by someone  
>> else.  The hyphen is used for SSIDs in callsigns (we are talking  
>> about Object names here) and the space character does have  
>> significance in the D-STAR world which is what these objects  
>> represent.  The D-PRS IGates for each repeater use a callsign like  
>> K5PRK-A because those are used for callsigns in the path portion of  
>> the APRS line (packet).  Therefore, they also use the same callsign  
>> for posits identifying the location of those IGates.
>>
>> The D-STAR repeater objects (generated in accordance with Bob's  
>> desire to have local repeater information made available to local  
>> hams on APRS, in this case via individually configured IGates) use  
>> the full D-STAR repeater callsign as their object name.  This  
>> callsign is always 8 characters.  The eighth character is the  
>> station ID (SSID) and will generally be A, B, C, or D for  
>> individual repeaters (multiple repeaters share can share the same  
>> first 7 characters).  Therefore, these are a couple of the  
>> technical reasons why the Object names for these objects contain  
>> one or more embedded spaces.
>>
>> Whether it gets displayed as K4HG A or K4HG   A is somewhat  
>> inconsequential IMO.  Whether it can be searched as K4HG%20A or  
>> K4HG%20%20%20A (example of URL with embedded spaces) makes a big  
>> difference, but only to the D-STAR operators that might want to use  
>> a particular database for queries.  What Steve does with the findU  
>> database is up to him.  I did not start this thread.
>>
>> I do agree that trailing spaces in an Object or Item name can  
>> probably be disregarded because that is what most authors have done  
>> since the publishing of the APRS spec.  I don't agree that properly  
>> designed (designed to the APRS spec) Object names need be changed  
>> just because someone doesn't like the way they look on their screen  
>> or because they didn't consider that option when coding their  
>> software.  There will ALWAYS be someone who doesn't like the way  
>> something looks on their screen and there will ALWAYS be someone  
>> who "has a better idea" years after something has been implemented.
>>
>> Hope this clarifies a little bit why the Object names are formatted  
>> the way they are and why it really doesn't make sense at this stage  
>> of the game to change them since the do adhere to the APRS spec.
>>
>> 73,
>>
>> Pete Loveall AE5PL
>> pete at ae5pl dot net
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>