[aprssig] Appalachian Trail Tracking

[Andrew P.]

FYI: For those wanting to do massive numbers of point-in-polygon tests for very convoluted polygons with thousands of vertices, this algorithm turned out to be very useful. Couple of orders of magnitude faster than the winding-rule algorithm.

Zalik & Kolingerova, "A cell-based point-in-polygon algorithm suitable for large sets of points", Computers & Geosciences 27 (2001) 1135-1145.

I've used this in the commercial products I've developed, and it made point-in-polygon checks go from the dominating processing overhead to lost-in-the-noise.

Andrew Pavlin, KA2DDO

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: John Gorkos <jgorkos at gmail.com>
Date: Tue, 28 Feb 2012 15:13:02 
To: <aprssig at tapr.org>
Subject: Re: [aprssig] Appalachian Trail Tracking

Usually, I'm pretty useless, but this sounds like something I might be able to help with.
First of all, there is some pretty good GIS data for the A.T. Here:
http://www.appalachiantrail.org/about-the-trail/mapping-gis-data/appalachian-trail-gis-gps-data
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:
1. 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)
2. 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."
  1. 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"
  2. 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.
  3. 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.

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.


John Gorkos
AB0OO




From:  "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to <mailto:ldeffenb at homeside.to> >
Reply-To:  TAPR APRS Mailing List <aprssig at tapr.org <mailto:aprssig at tapr.org> >
Date:  Mon, 27 Feb 2012 16:27:53 -0500
To:  TAPR APRS Mailing List <aprssig at tapr.org <mailto:aprssig at tapr.org> >
Subject:  Re: [aprssig] Appalachian Trail Tracking



 
 On 2/27/2012 4:13 PM, Bob Bruninga wrote:  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? 
 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.
 
  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. 
 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.
 
  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? 
 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.
 
 
  How long is data retention in your data base of Hessu's before we have to be sure to capture the data? 
 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.
 
  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. 
 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.
 Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
 
 _______________________________________________ aprssig mailing list aprssig at tapr.org <mailto:aprssig at tapr.org> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig