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

[Lynn W. Deffenbaugh (Mr)]

The data source is just that, the data source.  The raw data may be 
imported into whatever processing data structure any given software 
consumer may find more useful, including your left-to-right assignments 
approach.

Personally, I keep a (currently hard-coded, but soon to be loaded, 
parsed, and massaged) sorted list with the more detailed definitions 
located after the more generic ones.  One pass through the list and I 
have the most likely answer.  And for performance reasons, you really 
only need to do the lookup whenever the toCall changes for a stations, 
not necessarily on every packet.

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

On 10/24/2013 8:21 AM, Andrew P. wrote:
> 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 http://www.tapr.org/mailman/listinfo/aprssig
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20131024/ca1b65c4/attachment.html>