[aprssig] [aprsisce] Adding additional symbols

Heikki Hannikainen hessu at hes.iki.fi
Tue Oct 1 23:02:27 CDT 2013


On Wed, Oct 2, 2013 at 1:30 AM, Robert Bruninga <bruninga at usna.edu> wrote:

> 6)  Although I came up with this expansion room just for this purpose, I
> am totally swamped and cannot take it on bit by bit.  If someone would like
> to be the symbol CZAR to collect all of  the desires, and organize them,
> and then make a well thought out and justified proposal, that would help.
>
> I just found another link:  http://aprs.org/symbols.html
>
> So that is another job,  go through all of my evolved documents on Symbols piece
> by piece and identify any conflicts, overlaps, errors and make any
> specific recommendations on how I can clean them up.
>
> The main entry points are aprs11.html, aprs12.html, symbols.html and then
> all of the symbol related .TXT files they point to.  What a mess.
>

Whatever comes out of this should be produced in the form of a

MACHINE READABLE CONFIGURATION FILE

(JSON, XML, CSV, or YAML file) that could be loaded into different client
applications, without any need for the client software author to manually
track magic human-readable .html / .txt files in various URLs. That sort of
work is a completely unnecessarily duplicated effort for us all.

Such a configuration file defining symbols could possibly even be

UPDATED AUTOMATICALLY

to different client applications around the world, by those clients
downloading it from somewhere, without any need for the application author
to actually build and redistribute a new version of the client.

Something like this happens already: People can actually download Steven's
icon set files and install them in UI-View and a number of other apps
(that's what I put in aprs.fi actually). It's the closest thing to a
standard we have now! Too bad it only includes graphics, and not the text
definitions.

I currently manually maintain the Ham::APRS::DeviceID module, which
contains a machine-readable definition of APRS device identifiers (tocalls,
mic-e identifiers). Take a look at
http://cpansearch.perl.org/src/HESSU/Ham-APRS-DeviceID-1.06/DeviceID.pm and
scroll back a bit to see the @dstcall_regexps hash definition. I have to
manually track changes in http://www.aprs.org/aprs11/tocalls.txt and update
them in my code. If tocalls.txt was published in a machine-readable config
file format, that could simply be read in and used by all the client apps,
without the need for everyone to manually track quiet changes in
tocalls.txt.

Maybe I should extract that stuff from DeviceID's perl code and publish it
in YAML format instead. That'd make it more usable for APRSIS32 and other
apps in other languages. Lynn, would you be interested in using that for
device identification?

- Hessu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20131002/6ec5d125/attachment.html>


More information about the aprssig mailing list