Jump to content

Pocket Queries And Traveling


Bear and Ting

Recommended Posts

Jeremy, et all:

 

Ting and I are starting to plan our "honeymoon/anniversary" trip for May. This year we will be traveling across the US for some 9-14 days. We may or may not have internet access throughout that time. What I am wanting to do is set up Pocket Queries (PQ) that will overlap our route. However, we are limited to five queries and that may not cover our route. PQs cover areas we will not be hitting or if we try to do it "by state", it limits or illimtates caches (by limiting it to 500).

 

We want to be able to see all the caches in the area and eliminate the ones we won't be doing that day via the PQ. Is there a way that the limits can be raised? Maybe once a month or a quarter per user? Or, can another type of PQ be created for routes?

 

I know I am not the only one who could use this feature. I know it has the potential to put a load on an already loaded server, but if it is limited to just a few times per year per user, it might be worth the effort.

 

Bear and Ting :huh:

Link to comment

I just came back from a trip from MA to MI. I completed pocket queries that covered most of the area I was traversing by car.

 

You can only have 5 active PQs, but you can delete and add at will, so you can really have as many as you want - you could run 5, and as soon as the first is completed, delete it and replace it with a new one. (Really you'd probably have to wait til the next *day* - I think the limit is 5 per day.)

 

For my trip, I used Clayjar's Watcher program (free) and EasyGPS (free) and Microsoft Streets 2002 (the 2004 ver. is around $20).

 

Using the PQ, I would generate a request for 500 closest to the main cities I would be travelling through. Then I used GPS babel (free) and translated those GPX files for use in Streets, which allowed me to map all of the caches.

 

Then, when you find a cache you want to visit, you can open up the Watcher program and search by cache name (or waypoint) and you can then view all of the cache page information offline.

 

We changed our caching plans several times on the run by using Streets and Watcher. Then, if you're lazy like me, you just use EasyGPS to upload the new waypoints to your GPSr. Streets gave us the added benefit of routing us to all of the caches.

 

So, in short, if I read your request properly, I don't see a need for any special treatment from GC.com - you should be able to do what you need to do already!

Link to comment

I agree, I should be able to get alot of data with the five PQs per day. And, I have done that in that past, like when traveling from Indianapolis, IN to Columbia, SC to visit my folks. It works great when we (a) know our complete route and (:( we know where our internet access will be coming from. Neither is the case.

 

The way we are traveling is simple. Right now I have it down to three destinations. Depending on weather forecasts will depend on where we go. We'll pick the destination about a week ahead of time. Once picked, we will travel to that area and then head in a general direction, generally towards cluster of caches, so we will not know the complete route, kinda going where the wind blows us.

 

Secondly, I am not gonna know where my next internet access will be. And, I would have to access it the night before AND the next morning.

 

Bear (Jim)

Link to comment
We may or may not have internet access throughout that time.

Most public libraries now offer free internet access. You will probably have to your turn; and I'm not sure if you could connect your PDA to their machine or not. But you can still log your visits and print pages for a small fee.

 

Create yourself an email account through yahoo or something like that and you're all set.

Link to comment

Per Geo-Hog:

I'm not sure if you could connect your PDA to their machine or not. But you can still log your visits and print pages for a small fee.

 

Create yourself an email account through yahoo or something like that and you're all set.

 

Well, there are two ideas there. I will have my laptop, so I could transfer the GPX file to a media source (like a disk-on-key), if available. Then synch my GPSr and my Cachemate files. Printing is SO 2003ish! :D So, those ideas might work. As for the email account, my email is accessible world wide, so that won't be an issue. My only problem is (a) finding a library (or some other access point) and (:( not wanting to wait or pay for it.

 

Per Stunod:

I have 4 "scheduled" PQ and 1 left open. I have been able to create, run, delete, re-create & re-run that 5th PQ at least 3 or 4 times in a day with no problems. I'm not sure how far you could push this, though.

 

As for that, I've used those options before. Our biggest problem with this trip is the uncertainty of routes and the fact that if I say find 500 caches nearst this point, the radius is WAY too wide. I am only heading in one direction (or 180 degrees from a point), I don't need all the rest. I've tried in the past to find point further out, but that does not always work either.

 

What about this idea? What if the daily limit for a PQ is 2500 waypoints,500 for normal PQ's, up to 5 PQ's per day OR a route PQ where the user puts in 10-15 points and the PQ finds the nearest 1000 per route (limiting it to two routes)? This means that every route point would only find like 75-100 near the route point for each point. Is that feasible?

 

Bear

Link to comment
I've found with the 5 per day limit I've had more trouble sorting out which PQ number belongs to which spot I'm trying to look at.

I rename the file when I download it to avoid this problem.

 

On my last trip to California I had one each for Phoenix, Laughlin, Inland Empire, and San Diego. I keep them centered on areas I will be in and select only about 200 caches per query.

 

I've already cleared the Interstates between here and there, so it's easy to find single-new caches along the way by using the cache maps.

Link to comment
I've found with the 5 per day limit I've had more trouble sorting out which PQ number belongs to which spot I'm trying to look at.

We (gpx developers) have been requesting that the name of the PQ be included in the PQ-generated gpx file for more than a year now.

 

No response of any kind.

 

I wouldn't hold your breath.

 

There is, however, a trick that I have discovered: the PQ does have the date it was generated and a bounding rectangle in it. Because I think the bounding rectangle is determined by the particular caches returned in the PQ, it's not necessarily the same for subsequent versions of the same PQ, but it can be used to tell radically different PQs apart.

 

The biggest pain of the limit of 5 PQs is that I keep having to enter the same coordinates again and again for my travel PQs. It would be nice to have the ability to store the parameters for more PQs, having only 5 active at any one time.

 

But I'm not holding my breath for that, either.

Link to comment
I know it has the potential to put a load on an already loaded server ...

That all depends on who is doing the talking and who you want to believe and what is the purpose in making the statement. It seems to change depending on the above variables as can be seen in this thread.

 

So either PQs are a load on the server or they are not. It can't be both. My own feeling is if they are then the database has been poorly designed.

Link to comment

My post on getting started forum addresses thiis problem also.

 

>>>>>>>>Run a query out of the cache list just by marking those particular caches that one wants to have queried.

There seems to be no way to get one single pocker query now that allows for random caches.

I see you can do it with waypoints, but then there are no cache descriptions, logs, etc.

 

Could I mark whatever caches I was interested in, say, on a drive from

Texas to California but had nothing in common beyond my desire to get them

 

I see by the filter that I could just mark for the caches I am watching.

But this means many extra steps to add and delete those caches from my watch

list each time I was to run a query.

 

If there were a designated checkbox (for pocket query) next to each cache one could check it and it would be sent with the next pocket query.>>>>

 

If it were possible to mark individual caches on your route and place them in a query, would that not allow you to go to state cache maps and zoom in on the ones you wanted enroute along a linear travel line, intead of the radius that you now muse use?

Say you were riving and zoomed in to find the ones you felt you could get from the highway not too far off course.

Link to comment
I know it has the potential to put a load on an already loaded server ...

That all depends on who is doing the talking and who you want to believe and what is the purpose in making the statement. It seems to change depending on the above variables as can be seen in this thread.

 

So either PQs are a load on the server or they are not. It can't be both. My own feeling is if they are then the database has been poorly designed.

GJ,i think the post by Elias:

--------------------------------------------------------------------------------

Originally posted by Elias:

Pocket Queries are designed to use cached (no pun intended) versions of the cache pages. We can send out thousands of PQs with 300 caches each with little to no impact on the web server or database.

--------------------------------------------------------------------------------

 

is getting at "processing" impact,whereas requests for increased limits will have "bandwith" impacts.

 

Only my surmation...and been wrong before :rolleyes:

Link to comment

The cache information compiled into the PQs is cached on a per-cache basis (if I may use 'cache' far too often for one sentence). There is still the processing and memory hit of compiling the various caches into one GPX file and zipping the results.

 

The additional load on the database should be merely that required to select which caches to include, but the additional load on the system generating the PQs scales with caches sent. Since more than one server is involved, it can indeed be both. For the database server, the additional load is likely close to negligible, but for the PQ generating server, the additional load may well be significant. If the web server isn't involved except in setting up the PQs, for the web server the additional load would be irrelevant. (And then there's the bandwidth.)

 

So, GrizzlyJohn, it is not only both, but it is even more than that.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...