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

Andrew P. andrewemt at hotmail.com
Thu Oct 24 08:21:07 EDT 2013

The one problem I see with this whole scheme is that it requires a linear iteration over all possible patterns, because there is no encoded way to hierarchically organize the patterns to minimize the number of matches per tocall, and it could get a mismatch on a coarse pattern. Even if you find a match on a coarse pattern, you still have to try all the fine patterns under that coarse one to see if it is something else (ex.: APInnn for Icom versus APICxx for HA9MCQ PIC Igate versus APICQn for ICQ). So, it gets computationally worse as new subsets are defined.

I have a scheme (implemented in YAAC) that depended on the left-to-right assignment of more fixed characters for sub-divisions of a block, allowing me to do a sort of Btree search for efficiency. But, of course, that was broken by the APnnnD and APnnnU definitions.

Would it be possible to hierarchically link the patterns so if (for example), you matched on APIxxx, it would then try APICxx, and then APICQ, until a match failure occurred or the end of the finer patterns was reached?

I'm just trying to find a way to lower the burden on clients. Both the clients running on cheap computers with software TNCs (which therefore have extremely busy CPUs) and the giant clients taking full APRS-IS feeds could be impacted by an ever-growing list of tocall patterns that would ever-increase the computational burden on a per-packet basis (unless the client didn't need the lookup on a per-packet basis).

Andrew Pavlin, KA2DDO

Date: Thu, 24 Oct 2013 11:28:58 +0200
From: georg at op-co.de
To: aprssig at tapr.org
Subject: Re: [aprssig] APRS device identifiers (tocalls) in YAML,	XML and JSON

* Heikki Hannikainen <hessu at hes.iki.fi> [2013-10-24 08:43]:
> I would prefer taking a regexp library (pcre) and just throw the
> tocall spec found in the database file at it, instead of writing my
> own converters, since writing custom converters takes time and effort
> and may introduce bugs. String matching is sooooo a solved problem
> already. :)
+1 on that. I would really like to have an easy way (regular
expressions) to a) determine the client info block and b) extract the
version number.
My proposal would be to leave the tocall as-is, and add another
(slightly redundant) "regex" field that allows to match for the tocall
and to extract the version number, e.g. "^APWM(\d\d)$" (I hope I did not
botch the syntax now, but the point is just to make the intent clear).
Does YAML require any type of escaping for such strings?
73 de Georg DO1GL
APRSdroid - Open Source APRS Client for Android | http://aprsdroid.org/m
https://play.google.com/store/apps/details?id=org.aprsdroid.app | @APRSdroid

aprssig mailing list
aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20131024/8c0a4320/attachment.html>

More information about the aprssig mailing list