[aprssig] spaces in object names - and commas

[Heikki Hannikainen]

On Wed, 12 Aug 2009, Pierre Thibaudeau wrote:

> If you decide (like aprs.fi) to reduce multiple spaces to a single space,
> then "K5TIT B " and "K5TIT  B ", who should be two distinct entities would
> become one.

aprs.fi is indeed cleaning up object and item names heavily, and removing 
a lot of characters which are allowed by the spec, and effectively doing 
an s/\s+/ /g operation too. It's more of a bug than an intentional 
well-thought-out decision. I'll have to change this once I'm home and some 
sort of consensus has been reached here. I think I'll continue to trim 
leading and trailing spaces to ease up searching for these stations.

I don't know about the s/\s+/ /g yet (that's "replace consecutive 
whitespace with a single space" using a regular expression in Perl). I 
should probably make sure objects are displayed with the right amount of 
spaces (using the UTF-8 equivalent of   - 0xC2 0xA0), but still make 
them searchable with any amount of spaces (and have the user select from a 
list if multiple matches are found). Having multiple consecutive spaces is 
a pain in the butt in the usability and readability perspective, and I 
sure wish the specification would have specifically forbidden them in the 
first place. They're hard for my eyes, and think of blind users with 
speech synthesizers.

Even worse is that aprs.fi only allows a single entity to have the same 
name (after the "cleanup"). So, if someone sends an object " F0OO", it 
will overwrite/update the item "  F0OO" or the APRS station with callsign 
"F0OO". I will have to fix this too, and provide the "multiple matches 
found, pick one" view.

Case sensitivity is a bit more complicated issue to fix. I'm storing names 
in the correct case, but lookups (and unique keys) are case insensitive, 
so "Foo" will update "fOO". Data updates would have to be case sensitive, 
but end-user searches need to be case insensitive (and again provide the 
"pick one from here" view). It'll unfortunately be quite a lot of work for 
me, so I'll probably skip it now, as the users are not complaining loudly, 
even I'm breaking the specification here (too).

I was reading the spec a few weeks ago, and several bad words came out of 
my mouth when I figured that punctuation marks are allowed here. I was 
going to implement searching and simultaenous tracking of multiple 
targets, and the obvious intuitive way would have been to have the user 
search for 'OH7LZB-1, OH7LZB-2, OH7LZB-3'. That won't work for objects 
with commas in the name, but I think I'll ignore that and use the comma as 
a separator anyway. There are only 56 objects in my database which have a 
comma in the name, mostly repeater frequencies ("147,030"). Maybe I'll 
make it check for an exact match before splitting on the comma and going 
for a multiple target search. If someone sends three objects named "FOO", 
"BAR", and "FOO,BAR", he won't be able to look up both FOO and BAR at the 
same time, but...

I know it's really hard to write good and unambiguous specification 
documents, and think of all the use cases in advance, so I won't sue the 
working group for all of this. :)  It's also a lot of work to write 
software to conform to such a complicated specification, so bugs and 
non-conforming implementations will arise. I'd rather see the 
specification being updated to match either "what we really need and want 
to happen" or "what is currently happening in the real world", depending 
on the situation. It's not good if the specification matches neither, or 
if it's ambiguous.

   - Hessu