RWheeler
01-09-2012, 18:49
TRAC – Text Relay for Arrival at Camp
In the process of explaining to familyand friends that I plan to hike the Appalachian Trail, I got a verymixed set of reactions. The most typical reaction from my family wasconcern about knowing that I was alright. Not wanting to have toimpact my immersion in the trail and what it involves in order toease there minds, I was faced with the challenge of what to actuallydo.
Initially (and very briefly) I examinedthe idea of bringing along a SPOT device to fill this newrequirement. I didn't feel that paying for the device itself and thesubscription (especially reading reviews on customer serviceexperience with the company) was worth it for another device that I'dhave to carry – with no added benefit besides the one-waycommunication.
I liked the idea of being able to tracklocation on a Google Map, though. If I could have that level ofinformation, but provided from some different format, it'd likely beperfect. It was then that I diverted my attention to my cell phone.Because, hey, I already have that, it's capable of two-waycommunication, and with a pre-paid plan it's financially easier thana GPS-reliant method, without any long-term commitments.
That's when I came up with the idea forTRAC – a tracking system that utilizes texting to provide hikercheck-ins at specific locations. The text would include a categoryfor the location, a name for the location, and an optional message.This text would be sent to an online database containing the names,latitude/longitude, and other helpful details (state, elevation) ofshelters, towns, and other relevant locations. The program would thenrun a search on this database with the details in the text, find theappropriate location, and then relay this to a user-specific GoogleMap. A marker (TRACTack) would be placed at the coordinates of thecheck-in, along with a timestamp and the optional message, so anyonewho was provided with the link for the map could track the progress.In addition, the program could then send out update messages to anappropriate audience. This includes an e-mail with the location andlink to the map, a tweet, a new entry on a blog, or a status updateon a social networking site such as Facebook or Google+. Thepossibilities at this point are limited only by the desires of thehiker and what they set up before the hike.
Let's take a look at some examplecheck-ins to fully get an idea of what TRAC does. We'll start with athru-hiker going northbound and reaching Springer Mountain after aday on the Approach Trail. The exact text would read “F;Springer;Onthe AT”. The “F;” denotes the category that is being searched –in this example, Features. Well, is a category necessary? Let's takea look at the location used to check-in, “Springer.” Well,there's Springer Mountain, and Springer Mountain Shelter. A text thatsimply says “Springer Mountain” would produce results for both.However, telling the program that you mean a feature, you limit thesearch to those locations, effectively removing the Shelter as apossible result. The last bit of that text is the optional message,with a semi-colon to designate an end in the search term and thebeginning of the display message. Now, later on on this day, thehiker chooses to set up camp at Springer Mountain Shelter. He choosesto check-in again, letting others know that he's stopped for thenight. This time, he sends the text “S;Springer Mountain”. TRACsearches the database for shelters (the “S;”) and finds SpringerMountain Shelter, and updates the map accordingly. He chose not toinclude a message this time. His hike continues for the coming daysand nights, with him sending updates in the evening when he sets upcamp, as well as each time he bags a noteworthy peak. Eventually, hereaches Hot Springs. He decides that it's time to take a zero day. Hesends the text “T;Hot Springs;Zero day tomorrow” to send noticethat he's arrived at the town of Hot Springs. He's also lettingpeople know that he doesn't intend to hike tomorrow with the message.
The search results will be prioritizedbased on the distance from Springer – if there are multiple resultsfor the search, TRAC will pick whichever is closest to the southernterminus. In other words, whichever you reach first in a NOBO hikewill be the result that is marked and set as an update. In addition,with each consecutive update, the database will be limited forfurther results and only find locations that have a greater distancefrom Springer (further along the trail) than the most recent update.This will greatly limit the possibility of an inaccurate update.However, since the database can also easily handle distance fromKatahdin, that could just as easily be chosen as the factor to reducethe location pool. In addition, if a person were to flip-flop, TRACcould be switched from NOBO to SOBO mode on the flip, while stillmaintaining the southern limit on results. Distance from Springerwould continue to serve as a value to exclude results that werealready visited on the NOBO stretch, and once switched to a SOBOhike, the now-dynamic distance from Katahdin would exclude resultsthat were already visited to the North.
Now, this is currently something that I have in an "alpha" stage; I'm running tests on searches to see where other errors may occur, the specifics of server load during requests, and financially what the text communication would demand. Once I've done enough testing, and feel that it's working well enough, I'll be working with WhiteBlaze to see about possibly getting everything working for a larger audience. That way, WB members who are hiking in 2012 could be able to use it. However, based on the specific of bringing it larger scale (especially the text communication), it may be limited to who will actually be able to use it. Either way, once I finish this batch of testing, I'll be sharing the details for how things are being handled, so other users can follow the directions to set it up for themselves if they choose to host their own system.
Any feedback or questions (again, I won't be getting technical with everything yet, until I get it more refined) are welcomed!
In the process of explaining to familyand friends that I plan to hike the Appalachian Trail, I got a verymixed set of reactions. The most typical reaction from my family wasconcern about knowing that I was alright. Not wanting to have toimpact my immersion in the trail and what it involves in order toease there minds, I was faced with the challenge of what to actuallydo.
Initially (and very briefly) I examinedthe idea of bringing along a SPOT device to fill this newrequirement. I didn't feel that paying for the device itself and thesubscription (especially reading reviews on customer serviceexperience with the company) was worth it for another device that I'dhave to carry – with no added benefit besides the one-waycommunication.
I liked the idea of being able to tracklocation on a Google Map, though. If I could have that level ofinformation, but provided from some different format, it'd likely beperfect. It was then that I diverted my attention to my cell phone.Because, hey, I already have that, it's capable of two-waycommunication, and with a pre-paid plan it's financially easier thana GPS-reliant method, without any long-term commitments.
That's when I came up with the idea forTRAC – a tracking system that utilizes texting to provide hikercheck-ins at specific locations. The text would include a categoryfor the location, a name for the location, and an optional message.This text would be sent to an online database containing the names,latitude/longitude, and other helpful details (state, elevation) ofshelters, towns, and other relevant locations. The program would thenrun a search on this database with the details in the text, find theappropriate location, and then relay this to a user-specific GoogleMap. A marker (TRACTack) would be placed at the coordinates of thecheck-in, along with a timestamp and the optional message, so anyonewho was provided with the link for the map could track the progress.In addition, the program could then send out update messages to anappropriate audience. This includes an e-mail with the location andlink to the map, a tweet, a new entry on a blog, or a status updateon a social networking site such as Facebook or Google+. Thepossibilities at this point are limited only by the desires of thehiker and what they set up before the hike.
Let's take a look at some examplecheck-ins to fully get an idea of what TRAC does. We'll start with athru-hiker going northbound and reaching Springer Mountain after aday on the Approach Trail. The exact text would read “F;Springer;Onthe AT”. The “F;” denotes the category that is being searched –in this example, Features. Well, is a category necessary? Let's takea look at the location used to check-in, “Springer.” Well,there's Springer Mountain, and Springer Mountain Shelter. A text thatsimply says “Springer Mountain” would produce results for both.However, telling the program that you mean a feature, you limit thesearch to those locations, effectively removing the Shelter as apossible result. The last bit of that text is the optional message,with a semi-colon to designate an end in the search term and thebeginning of the display message. Now, later on on this day, thehiker chooses to set up camp at Springer Mountain Shelter. He choosesto check-in again, letting others know that he's stopped for thenight. This time, he sends the text “S;Springer Mountain”. TRACsearches the database for shelters (the “S;”) and finds SpringerMountain Shelter, and updates the map accordingly. He chose not toinclude a message this time. His hike continues for the coming daysand nights, with him sending updates in the evening when he sets upcamp, as well as each time he bags a noteworthy peak. Eventually, hereaches Hot Springs. He decides that it's time to take a zero day. Hesends the text “T;Hot Springs;Zero day tomorrow” to send noticethat he's arrived at the town of Hot Springs. He's also lettingpeople know that he doesn't intend to hike tomorrow with the message.
The search results will be prioritizedbased on the distance from Springer – if there are multiple resultsfor the search, TRAC will pick whichever is closest to the southernterminus. In other words, whichever you reach first in a NOBO hikewill be the result that is marked and set as an update. In addition,with each consecutive update, the database will be limited forfurther results and only find locations that have a greater distancefrom Springer (further along the trail) than the most recent update.This will greatly limit the possibility of an inaccurate update.However, since the database can also easily handle distance fromKatahdin, that could just as easily be chosen as the factor to reducethe location pool. In addition, if a person were to flip-flop, TRACcould be switched from NOBO to SOBO mode on the flip, while stillmaintaining the southern limit on results. Distance from Springerwould continue to serve as a value to exclude results that werealready visited on the NOBO stretch, and once switched to a SOBOhike, the now-dynamic distance from Katahdin would exclude resultsthat were already visited to the North.
Now, this is currently something that I have in an "alpha" stage; I'm running tests on searches to see where other errors may occur, the specifics of server load during requests, and financially what the text communication would demand. Once I've done enough testing, and feel that it's working well enough, I'll be working with WhiteBlaze to see about possibly getting everything working for a larger audience. That way, WB members who are hiking in 2012 could be able to use it. However, based on the specific of bringing it larger scale (especially the text communication), it may be limited to who will actually be able to use it. Either way, once I finish this batch of testing, I'll be sharing the details for how things are being handled, so other users can follow the directions to set it up for themselves if they choose to host their own system.
Any feedback or questions (again, I won't be getting technical with everything yet, until I get it more refined) are welcomed!