Preparation for my Road Trip
Planning is not really in my vocabulary.
That is why Geocaching has been so good for me. Something that is hard for me is now something I can do . . . as long as it is planning for caching . . .
I only had a few days to get ready for the trip, but I got five new Pocket Queries on each of those days.
To create the PQs, I looked at my Mapsource maps and picked out some widely-spaced places along possible routes. I got the coordinates for a National Monument south of Phoenix, a high plateau on the way to I-40, Canyon de Chelly National Park, Gallup, Cortez, Great Sand Dunes National Monument, my destination west of Denver, Zion National Park, and Red Rocks Canyon outside Las Vegas, etc.
Using those coordinates as the center points for my 100-mile diameter circles, I created the PQs. Because I knew I wasn't going to have time to do any long hikes, I limited the PQs to caches having a Terrain rating of '2.5' and under. I even limited the Difficulty to '3' and under, because I didn't want to spend a lot of time looking for a cleverly-cammoed cache.
Then using some of the suggestions offered up in this thread, I continued my preparations.
In GSAK, I created a new Database I called "Road Trip." I put all the data from the several PQs into that Database, ending up with almost 4000 caches in the database.
In Mapsource, I created a few alternate Routes. Mapsource has a setting under Edit/Preferences where you select the kind of roads you want to travel on. You can even create a route that follows major highways for part of it, and minor highways for the rest of it, as I did with my first route through Arizona.
I saved each of these Routes as .gpx files and put them in a folder on my laptop under Geocaching/Routes so I could find them easily.
Now, before using the Arc/Poly filter in GSAK, I did the "Last 2 DNF filter" for the entire database to select the caches that couldn't be found by the last two cachers. On a road trip, I really didn't want to look for a cache others had had difficulty finding.
I deleted all the caches returned by that filter.
After that, I filtered the data by state, so GSAK didn't have to sort through all 3473 caches in that "Road Trip" database for the first "Arc/Poly" filter at the beginning of my adventure.
I chose a width of five miles along that first section. That was a distance I thought I might possibly divert if a cache looked interesting enough.
After running the filter, and seeing that it returned well under 500 caches, the waypoint limit for my Vista C, I sent those caches to my GPSr. If that Arc/Poly filter had returned more than 500 caches, I would have narrowed the distance along the route to only four miles.
Now, the GPSr was ready. I just had to get my Palm M500 ready.
I cleared the filters in GSAK and set a new filter for only the caches in Arizona. I ran that and then Exported the data in the Palm .pdb format, creating a file called Arizona.pdb. I cleared that filter and filtered for the caches in Colorado. With those caches selected, I Exported the data as another .pdb file for my Palm. I did this for each state in my Road Trip database.
Doing this gave me a manageable chunk of data for each state. Now, in Cachemate on my Palm, I created new databases for each state.
Using the Install tool on my Palm Desktop, I made sure each of those .pdb files (Arizona.pdb, Colorado.pdb, Utah.pdb, NewMexico.pdb, and Nevada.pdb) would install to the card on my Palm, and not on the main, limited memory of the Palm itself.
After doing the HotSync, I put the Arizona data in the "Not Found" folder in the Cachemate Arizona database. Likewise, I put the Colorado.pdb file Exported from GSAK in the "Not Found" folder of the Cachemate Colorado database.
Now, I had all the data on my laptop, all the data in the state databases on the data card on my Palm, and caches for the first section of my trip on my GPSr . . . I was set.
Because of the Vista C's 500-waypoint limit, I knew I was going to have to go through part this procedure a few times along the trip. However, I also knew I would need breaks for food or coffee every few hundred miles, so this wasn't going to be a hardship for me, and it would keep me in practice.
This also gave me the flexibility of changing my route along the way. If I found myself on a different highway than I thought I was going to take, I could create a new route for that highway, using the Edit/Preferences in Mapsource to make sure it would choose that type of road, and not the Interstate parallel to where I was. I could save that new Route as a .gpx file, and then use it in the Arc/Poly filter in GSAK.
Before sending that new set of caches to my GPSr, I would have to delete the "Geocaches" that were already on it. I figured I would keep the "Geocaches Found" on my GPSr before sending the new waypoints to it.
Since the Palm already had all the data on it, I wouldn't have to do another HotSync.
This would give me something to do during the break. It probably wouldn't even take as long as it would to drink that cup of coffee I needed to keep me alert for the next couple hundred miles of highway.
That is why Geocaching has been so good for me. Something that is hard for me is now something I can do . . . as long as it is planning for caching . . .
I only had a few days to get ready for the trip, but I got five new Pocket Queries on each of those days.
To create the PQs, I looked at my Mapsource maps and picked out some widely-spaced places along possible routes. I got the coordinates for a National Monument south of Phoenix, a high plateau on the way to I-40, Canyon de Chelly National Park, Gallup, Cortez, Great Sand Dunes National Monument, my destination west of Denver, Zion National Park, and Red Rocks Canyon outside Las Vegas, etc.
Using those coordinates as the center points for my 100-mile diameter circles, I created the PQs. Because I knew I wasn't going to have time to do any long hikes, I limited the PQs to caches having a Terrain rating of '2.5' and under. I even limited the Difficulty to '3' and under, because I didn't want to spend a lot of time looking for a cleverly-cammoed cache.
Then using some of the suggestions offered up in this thread, I continued my preparations.
In GSAK, I created a new Database I called "Road Trip." I put all the data from the several PQs into that Database, ending up with almost 4000 caches in the database.
In Mapsource, I created a few alternate Routes. Mapsource has a setting under Edit/Preferences where you select the kind of roads you want to travel on. You can even create a route that follows major highways for part of it, and minor highways for the rest of it, as I did with my first route through Arizona.
I saved each of these Routes as .gpx files and put them in a folder on my laptop under Geocaching/Routes so I could find them easily.
Now, before using the Arc/Poly filter in GSAK, I did the "Last 2 DNF filter" for the entire database to select the caches that couldn't be found by the last two cachers. On a road trip, I really didn't want to look for a cache others had had difficulty finding.
I deleted all the caches returned by that filter.
After that, I filtered the data by state, so GSAK didn't have to sort through all 3473 caches in that "Road Trip" database for the first "Arc/Poly" filter at the beginning of my adventure.
I chose a width of five miles along that first section. That was a distance I thought I might possibly divert if a cache looked interesting enough.
After running the filter, and seeing that it returned well under 500 caches, the waypoint limit for my Vista C, I sent those caches to my GPSr. If that Arc/Poly filter had returned more than 500 caches, I would have narrowed the distance along the route to only four miles.
Now, the GPSr was ready. I just had to get my Palm M500 ready.
I cleared the filters in GSAK and set a new filter for only the caches in Arizona. I ran that and then Exported the data in the Palm .pdb format, creating a file called Arizona.pdb. I cleared that filter and filtered for the caches in Colorado. With those caches selected, I Exported the data as another .pdb file for my Palm. I did this for each state in my Road Trip database.
Doing this gave me a manageable chunk of data for each state. Now, in Cachemate on my Palm, I created new databases for each state.
Using the Install tool on my Palm Desktop, I made sure each of those .pdb files (Arizona.pdb, Colorado.pdb, Utah.pdb, NewMexico.pdb, and Nevada.pdb) would install to the card on my Palm, and not on the main, limited memory of the Palm itself.
After doing the HotSync, I put the Arizona data in the "Not Found" folder in the Cachemate Arizona database. Likewise, I put the Colorado.pdb file Exported from GSAK in the "Not Found" folder of the Cachemate Colorado database.
Now, I had all the data on my laptop, all the data in the state databases on the data card on my Palm, and caches for the first section of my trip on my GPSr . . . I was set.
Because of the Vista C's 500-waypoint limit, I knew I was going to have to go through part this procedure a few times along the trip. However, I also knew I would need breaks for food or coffee every few hundred miles, so this wasn't going to be a hardship for me, and it would keep me in practice.
This also gave me the flexibility of changing my route along the way. If I found myself on a different highway than I thought I was going to take, I could create a new route for that highway, using the Edit/Preferences in Mapsource to make sure it would choose that type of road, and not the Interstate parallel to where I was. I could save that new Route as a .gpx file, and then use it in the Arc/Poly filter in GSAK.
Before sending that new set of caches to my GPSr, I would have to delete the "Geocaches" that were already on it. I figured I would keep the "Geocaches Found" on my GPSr before sending the new waypoints to it.
Since the Palm already had all the data on it, I wouldn't have to do another HotSync.
This would give me something to do during the break. It probably wouldn't even take as long as it would to drink that cup of coffee I needed to keep me alert for the next couple hundred miles of highway.
0 Comments:
Post a Comment
<< Home