[aprssig] Symbol set revisions
Heikki Hannikainen hessu at hes.iki.fiThu Apr 17 19:40:09 UTC 2008
- Previous message: [aprssig] Symbol set revisions
- Next message: [aprssig] Symbol set revisions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [aprssig] Symbol set revisions
- Next message: [aprssig] Symbol set revisions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
