[aprssig] APRS device identifiers (tocalls) in YAML, XML and JSON

[Lynn W. Deffenbaugh (Mr)]

Great first cut Hessu!  Thanks for the effort, and especially for the 
various supported formats.

I just can't believe I never noticed that everything ending in D and U 
are allocated, even in the original tocalls.txt:

>        APnnnD  Painter Engineering uSmartDigi D-Gate DSTAR Gateway
>        APnnnU  Painter Engineering uSmartDigi Digipeater

which becomes:

> - tocall: AP???D
> vendor: Painter Engineering
> model: uSmartDigi D-Gate
> class: dstar
> - tocall: AP???U
> vendor: Painter Engineering
> model: uSmartDigi Digipeater
> class: digi

I'll have to see if I can remember that as I increment my version 
numbers, just to avoid any ambiguities.

Is aprsd truly only allocated numeric versions?  Or am I mis-reading the 
nnn vs ??? in the tocall: elements?

> - tocall: APDnnn
> vendor: Open Source
> model: aprsd
> class: software
> os: Linux/Unix

Looking further down the list, how is a * different than a ? or n, 
specifically:

> - tocall: APTT*
> vendor: Byonics
> model: TinyTrak
> class: tracker
and
> - tocall: APU2*
> vendor: Roger Barker, G4IDE
> model: UI-View32
> class: software
> os: Windows

What are your intended implications and uses of the classes? 
Particularly "app" vs "software"?  There's a lot of folks out there that 
take APRSIS32 on Windows mobile and/or run it on XP tablets.  So which 
is it?  Also is there any expectations that "tracker" are deaf?  Or is 
it acceptable that they might do messaging?

I may have more questions and I pull this into use in APRSISMO (name to 
be changed) and then later into APRSISCE/32.  I'll likely be using the 
XML versions myself, since I already have parsers that load those neatly 
for me.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 10/23/2013 5:23 PM, Heikki Hannikainen wrote:
> Tonight i started the effort of publishing a machine-readable APRS
> device/software identification database. This is basically tocalls.txt
> in a format that can be used by software without another manual
> conversion job from Bob's text format. It also contains aprsd's
> identification which is not present in tocalls.txt.
>
> https://github.com/hessu/aprs-deviceid
>
> The master copy is in YAML, which I personally prefer for editing by
> hand using my favourite ASCII text editor. The format is suitable for
> configuration files and such, and allows #comments.
>
> https://github.com/hessu/aprs-deviceid/blob/master/tocalls.yaml
>
> Then there's a validator script which calls a YAML parser and then
> checks the contents a bit (makes sure mandatory keys are present, and
> non-mandatory keys are in the supported set). Should prevent most of
> the stupid editing mistakes.
>
> The validator then produces XML and JSON files which are easy to read
> in most programming languages (if you don't wish to bring in a YAML
> parser library).
>
> Pretty-printed JSON (with some newlines and whitespace):
> https://github.com/hessu/aprs-deviceid/blob/master/generated/tocalls.pretty.json
>
> Dense JSON (no whitespace for readability):
> https://github.com/hessu/aprs-deviceid/blob/master/generated/tocalls.dense.json
>
> Dense XML (feedback on schema is welcome):
> https://github.com/hessu/aprs-deviceid/blob/master/generated/tocalls.xml
>
> Documentation in the README file:
> https://github.com/hessu/aprs-deviceid/blob/master/README.md
>
> Click on the "Raw" button to find a link to the raw files.
>
> Mic-E identifiers are still missing. I'll add it, and then make the
> Ham::APRS::DeviceID use this database.
>
> Note that I didn't actually use this version of the database for
> anything yet, I just put it together tonight. There are probably some
> errors in the contents.
>
> - Hessu
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>