Order Tray | Contact Us | Home | SIG Lists

[aprssig] Symbol set revisions

Heikki Hannikainen hessu at hes.iki.fi
Thu Apr 17 19:40:09 UTC 2008


   Hi Bob,

On Thu, 17 Apr 2008, Robert Bruninga wrote:

>> This requires two technical things:
>> 1) A machine-readable configuration file,
>
> Unfortunately, this will be application specific, since all
> existing applications did it differently.

   I would still like to argue, that if the published symbol specification 
would be in a machine-readable format instead of a free-form text file, it 
would be possible:

   1) for people implementing *new* applications to make their new 
applications read this new format, so that the symbols could be easily 
updated in those applications

   2) for people maintaining current applications to update their 
applications to read this new format

   3) for other people to write little conversion scripts to convert this 
new format to the formats used by existing, unmaintained applications

   The reason each application currently has a different symbol 
configuration and image format is that they had no other option but to 
come up with one. It doesn't necessarily have to be like this in the 
future. If there would be a standard format, I'm sure people would be 
happy to use it, and this problem would slowly go away for good.

   If any significant effort is put into revising the symbol set, it would 
be very useful if the produced new specification would be published in a 
machine-readable format together with the symbol images. If it's easy and 
straightforward to parse, it is more likely to become commonly used in a 
short timeframe.

   Here's my suggestion how it could look like:

- A single ZIP file containing both the specification file + the symbol 
images in a directory tree. The specification file has a fixed name, say, 
symbols.cfg (or whatever, as long as it's the same every time).

   The specification file could be a CSV file, listing the symbol table and 
character, a length-limited short name for the symbol, a longer 
description for those symbols with a non-obvious short name, flags telling 
whether this image is overlayable and rotatable, and the name of the 
symbol image file. Something like this:

"table","symchar","short_description","long_description","overlayable","rotatable","image"
"/,"!","Police Stn","Police station",0,0,"symbols\pri\033.png"
"/","""","No Symbol","No Symbol",0,0,"symbols\pri\034.png"
"/","#","Digi","Digipeater",0,0,"symbols\pri\035.png"
... more primary symbols ...
"\","!",Emergency,A place of emergency,1,0,"symbols\alt\033.png"
"\","""",No Symbol,No Symbol,1,0,"symbols\alt\034.png"
"\","#",Digi,Digipeater,1,0,"symbols\alt\035.png"

Note how a " character is represented as two "'s in a "-delimited string. 
You could edit this in your favourite spreadsheet (excel, openoffice) if 
you like, and it'd be pretty easy to write your application to parse this.

Then, the files referenced by the .cfg file in the same ZIP file. The file 
paths and names could change from ZIP revision to another, as long as the 
.cfg file points each symbol code to the correct symbol image:

symbols\pri\033.png
symbols\pri\034.png
...
symbols\alt\033.png
symbols\alt\034.png

   If the new symbol set would be published in this kind of format, it 
would take me just one evening to write code to import the new symbols to 
aprs.fi. The next time the symbol set would be updated, it would take just 
a couple minutes to update. It would also take me just one good evening to 
write code to convert this to ui-view's format, and probably the effort 
for xastir wouldn't be much harder.

   If the new symbol set is published in the current format, it'll take 
more than one evening to update to it to aprs.fi. It'll take, again, more 
than one evening the next time it is revised. I feel it's time wasted, 
since it *could* be automated with a little coordination, and the time 
could be spent building something new.

   CSV is very simple to edit by non-technical people (using spreadsheet 
applications), and quite easy to produce by hand. XML would be better, 
more cleanly extendable, and easier to validate, but maybe it'd be too 
advanced to be accepted right now. :)

> I am so glad to hear that you are considering displaying the
> ROTATABLE symbols from the original APRS.

   Actually, I'm not considering it, it's been there since January. 8)

   - Hessu, OH7LZB





More information about the aprssig mailing list