<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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.<br>
<br>
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.<br>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32<br>
<br>
On 10/24/2013 8:21 AM, Andrew P. wrote:<br>
</div>
<blockquote cite="mid:BAY170-W29F845B4FDFC5B7AFA6735B80C0@phx.gbl"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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).<br>
<br>
Andrew Pavlin, KA2DDO<br>
<br>
<div>Date: Thu, 24 Oct 2013 11:28:58 +0200<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:georg@op-co.de">georg@op-co.de</a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
Subject: Re: [aprssig] APRS device identifiers (tocalls) in
YAML, XML and JSON<br>
<br>
<pre>* Heikki Hannikainen <a class="moz-txt-link-rfc2396E" href="mailto:hessu@hes.iki.fi"><hessu@hes.iki.fi></a> [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 | <a moz-do-not-send="true" href="http://aprsdroid.org/m" target="_blank">http://aprsdroid.org/m</a>
<a moz-do-not-send="true" href="https://play.google.com/store/apps/details?id=org.aprsdroid.app" target="_blank">https://play.google.com/store/apps/details?id=org.aprsdroid.app</a> | @APRSdroid
</pre>
<br>
_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="http://www.tapr.org/mailman/listinfo/aprssig">http://www.tapr.org/mailman/listinfo/aprssig</a></div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="http://www.tapr.org/mailman/listinfo/aprssig">http://www.tapr.org/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
</body>
</html>