<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>Well… This is a bit harder than I though. Average message rate through APRS-IS is in the 40 msgs/sec range right now. The way APRS-Alert is set up, it first filters on call sign (I.e. It has a list of call signs that people are interested in), and then it applies any geospatial rules on the far more limited subset of interesting calls that get through, versus against the entire message stream.</div><div>Looking for "all stations in a geographic area" means that every position report needs to be geospatially tested against every zone that we find interesting. Right now, my setup takes about 3ms per "within" test, meaning theoretically, I could do about 8-10 zone tests per message per second. So, for special cases, I can check every position to see if it's coming from someone on the Appalachian Trail (I created a polygon that encloses the entire length of the trail to do a st_within() test against), but I can't make a feature on the web site that allows people to say "notify me any time ANY station enters zone X". Same thing for another great idea I had: sent an APRS message or other notification (I.e. Sms, if the call sign is registered) to any station entering an active Severe Thurnderstorm or Tornado Warning box. Again, unfortunately, the math works against me: testing every inbound position against every active severe weather zone is more computationally intensive than I'm willing to throw hardware at, especially on a night like last night, where we had multiple large swaths of the US covered with blizzard warnings, tornado warnings, etc.</div><div>Granted, I'm not as committed to this financially as Hessu is with APRS.FI. I'm sure I could get an amazon cloud instance, or put "real" hardware in a "real" datacenter that could keep up. I might yet do that, since I have access to said hardware and colo, but for the immediate future, it's harder than it looks.</div><div><br></div><div>John Gorkos</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> John Gorkos <<a href="mailto:jgorkos@gmail.com">jgorkos@gmail.com</a>><br><span style="font-weight:bold">Date: </span> Tue, 28 Feb 2012 10:13:02 -0500<br><span style="font-weight:bold">To: </span> TAPR APRS Mailing List <<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [aprssig] Appalachian Trail Tracking<br></div><div><br></div><div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Usually, I'm pretty useless, but this sounds like something I might be able to help with.</div><div>First of all, there is some pretty good GIS data for the A.T. Here:</div><div><a href="http://www.appalachiantrail.org/about-the-trail/mapping-gis-data/appalachian-trail-gis-gps-data">http://www.appalachiantrail.org/about-the-trail/mapping-gis-data/appalachian-trail-gis-gps-data</a></div><div>That can be sucked into Postgres pretty easily. Next, this would be a good excuse to make some additions to APRS-Alert (that darned web site that I put together that sends text messages/emails when a station enters or leaves a zone). Seems to me it shouldn't be too painful to do two things there:</div><ol><li>add an upload option for shape files, or better yet, include a set of pre-defined zones for people versus just a point/radius (I.e. States, counties, lakes, NWS zones, etc)</li><li>Add a "log this data" option as opposed to a "send me a text message" notification. The use case is "Bob wants to collect all of the packets sent from inside a specific zone for the next 30 days."</li><ol><li>Bob logs into the APRS-Alert web site and creates a new rule that says he's interested in all position packets sent from inside zone "Appalacian Trail"</li><li>On the Notification Page, he creates a new notification rule that sends him a reminder once a week of the data that's been collected, including a URL he can use to fetch that data.</li><li>When he clicks on the URL, he's presented a list of options for viewing the data, including KML, raw APRS, and maybe shape file.</li></ol></ol><div>Just brainstorming here. Bob, does this sound like what you're looking for? I'd have to place some limits on the data size and time limit for collection. Some yahoo is sure to set up a rule that says "record all position packets in the state of california for the next 12 months" and suddenly my 2TB drive starts looking pretty small. I could probably do a rolling window in time? I don't want to tread on the territory of aprs.fi and Hessu's work, but this seems like my niche.</div><div><br></div><div>John Gorkos</div><div>AB0OO</div><div><br></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> "Lynn W. Deffenbaugh (Mr)" <<a href="mailto:ldeffenb@homeside.to">ldeffenb@homeside.to</a>><br><span style="font-weight:bold">Reply-To: </span> TAPR APRS Mailing List <<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>><br><span style="font-weight:bold">Date: </span> Mon, 27 Feb 2012 16:27:53 -0500<br><span style="font-weight:bold">To: </span> TAPR APRS Mailing List <<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [aprssig] Appalachian Trail Tracking<br></div><div><br></div><div>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
On 2/27/2012 4:13 PM, Bob Bruninga wrote:
<blockquote cite="mid:015301ccf594$a9f396a0$fddac3e0$@edu" type="cite"> <pre wrap="">Can you or Hessu think of a way to aggregate all this data into one 2000
mile long string of data? Or do we just collect callsign reports and then
wait till we have enough data and then manually connect them?</pre>
</blockquote>
<br>
I've been playing around with OpenStreetMap data recently and they
seem to have the Appalachian Trail in as a way of connected nodes.
It'd be really neat if there was an easy way to detect an APRS
position report close to this line to get an automated way of
collecting points, but I'm not that good with geo-relations in
PostGreSQL (yet). So for now, the only thing I would know is to
manually collect and connect reports as submitted by the hikers
using callsign and date/time range.<br>
<br>
<blockquote cite="mid:015301ccf594$a9f396a0$fddac3e0$@edu" type="cite"> <pre wrap="">Even if we came up with a clever SYMBOL or other flag to indicate the AT,
the chances are that some will forget it and do it wrong, so we will end uphaving to manually connect the data anyway.</pre>
</blockquote>
<br>
Yeah, that's probably not even worth asking them to do, IMHO. We'll
get more people telling us when they were there than we would people
getting the symbol right.<br>
<br>
<blockquote cite="mid:015301ccf594$a9f396a0$fddac3e0$@edu" type="cite"> <pre wrap="">So unless you have a clever idea, Im just going to ask everyone to REPORT
their DATES and TIMES and CALLSIGN when they were actually on the trail andwe can aggregate it later?</pre>
</blockquote>
<br>
That's a good start. If we have that information, we can always do
it the hard way. If we miss capturing that data, we might miss our
last chance to get what you're after.<br>
<br>
<br>
<blockquote cite="mid:015301ccf594$a9f396a0$fddac3e0$@edu" type="cite"> <pre wrap="">How long is data retention in your data base of Hessu's before we have to be
sure to capture the data?</pre>
</blockquote>
<br>
My DB is limited to 5 days (sufficient for my purposes), but I store
all raw packets forever (for now), so I could go back and resurrect
paths if necessary. But I believe Hessu keeps posits in his DB for
a LOT longer than my 5 days and has some good queriability to boot.<br> <br>
<blockquote cite="mid:015301ccf594$a9f396a0$fddac3e0$@edu" type="cite"> <pre wrap="">We will ask all hikers to use a 2 minute rate while hiking unless they are
running Proportional Pathing, then a 1 minute rate is the same thing.</pre> </blockquote>
<br>
Did AL0I-7 do one of your "destination" posits earlier today? If
not, then he's backtracking for some reason today. Hopefullly the following screen cap will come through. His first posit was to the SW, then he jumped to the NE and is now working his way back. Last posit was 1.75 hours ago.<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br> <br>
</div></div>
_______________________________________________
aprssig mailing list
<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><a href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a></span></div></div></span></body></html>