All caches in a state

[+Renegade Knight]

While I disagree with the option to get 'state queries' for a number of reasons, it is only fair to mention that Garmin's CX units don't have a limit on the number of caches that you can load, if you load them as POIs.

 

That's one reason I have not upgraded my GPS V.

10,000 waypoints is much more reasonable for a Geocaching GPS. More waypoints on your equipment is part of the larger solution.

 

When I started I could get all of Idaho on a PQ and load all of Idaho in my GPS. That was pretty nice.

Edited April 11, 2007 by Renegade Knight

[+VeryLost]

I know you can find WiFi access is many, many places... there are also hotels, libraries, etc... however, I often stay at KOAs and other camping areas when my wanderlust strikes. Most of these areas don't have WiFi... at least they didn't the last time I was able to wander.

 

I expect you're right. Last major caching day-trip I took, I managed to go hours without even seeing a McDonald's - serious rural journey Lots and lots of dirt roads and farmland, low rolling hills, the occasional cow. I went 300 miles without ever getting on a major road. It was a great day, but I doubt there was much selection of WiFi out in the kind off area I wanted to be in.

 

And again... not saying I can't go out and make a stop at a coffee shop/library/or any other place and pick up a WiFi to use... .just saying if there is an easier option, I'd pay a small fee for it.

 

Exactly. I certainly appreciate all the suggestions on how to get the data, etc. I'm already familiar with how to get a state-wide data set with PQs, though, and none of these suggestions quite meet the impromptu criteria.

 

Several people have given detailed answers about why such a feature wouldn't be useful to them, which is perfectly valid of course. Heck, apart from the occasional weekend when my feet start to itch, it wouldn't be useful to me either. When those weekends occur, though, I'd happily drop two or three bucks for a statewide file as I was on my way out the door.

 

So far I haven't seen anything demonstrating that it's a bad idea in general, though.

[+Renegade Knight]

...So far I haven't seen anything demonstrating that it's a bad idea in general, though.

 

Most people would be better served by an all cache radius that matches their wanderlust radius. Especially for folks like me who live in the corner of a state, or folks back East who live in a dinky state, or Europe.

 

One Wanderlust Radius PQ would be better than multiple states.

[+mtn-man]

Last major caching day-trip I took, I managed to go hours without even seeing a McDonald's - serious rural journey Lots and lots of dirt roads and farmland, low rolling hills, the occasional cow. I went 300 miles without ever getting on a major road. It was a great day, but I doubt there was much selection of WiFi out in the kind off area I wanted to be in.

My question would be, did you pass by more than 500 caches?

 

So far I haven't seen anything demonstrating that it's a bad idea in general, though.

I can give you three.

 

Server load on people accessing the site to look around, server load on the site for people trying to pull regular pocket queries and server load for people trying to log their finds.

[+sbell111]

I know you can find WiFi access is many, many places... there are also hotels, libraries, etc... however, I often stay at KOAs and other camping areas when my wanderlust strikes. Most of these areas don't have WiFi... at least they didn't the last time I was able to wander.

Good news. Most KOAs now have wifi.

[BRTango]

I know you can find WiFi access is many, many places... there are also hotels, libraries, etc... however, I often stay at KOAs and other camping areas when my wanderlust strikes. Most of these areas don't have WiFi... at least they didn't the last time I was able to wander.

Good news. Most KOAs now have wifi.

 

That works... thanks

[+tozainamboku]

So far I haven't seen anything demonstrating that it's a bad idea in general, though.

I can give you three.

 

Server load on people accessing the site to look around, server load on the site for people trying to pull regular pocket queries and server load for people trying to log their finds.

• Server load on people accessing the site to look around
  Pocket queries are generated on a separate server and in addition by using the mega/state PQ and GSAK to select caches from this you would avoid the load on the severs that the current methods require when planning this kind of road trip.
  
• Server load on the site for people trying to pull regular queries
  Since the topic is "How much would you pay" I assume that a pricing strategy could be worked out to discourage the use of this kind of query except by those that really need it and only for occassional use. It shouldn't have much impact on the regular pocket queries especially if it can reduce the number of users who currently run lots of weekly/daily pocket queries to maintain an off-line database for the same purpose.
  
• Server load for people trying to log their finds
  See first bullet
  

Initially I was oppose to the idea as it looked as if it was a way to create a large offline database beyond what is needed by an individual to go caching. The limits on pocket queries, I believe, are in part due to Geocaching.com wanting to protect their database from being copied by another website. The idea of charging for this feature for those that feel they need it - perhaps with a separate license they must agree to to prevent abuse - means it could be workable and even in the interest of Geocaching.com and the rest of the geocaching community. I'm not sure if selling states or other predefine regions would work or if allowing a mega PQ with a large number of caches - say 5000 - would be better.

[+Miragee]

Days Inn motels also had great WiFi . . . from their parking lots . . .

[BRTango]

That gets me back to the topic title again "how much would you pay".

 

I do think it should be based on a per cache basis if it was done. I am still thinking like a penny a cache. That would discourage running this two or three times a month. I also think the number of people that would do this is small (talking about the "wandering" types, not those that are updating an offline database with this request), so is the need actually there.

 

I think a penny a cache would be reasonable.

[+baloo&bd]

I do think it should be based on a per cache basis if it was done. I am still thinking like a penny a cache. That would discourage running this two or three times a month. I also think the number of people that would do this is small (talking about the "wandering" types, not those that are updating an offline database with this request), so is the need actually there.

 

If this is for the "wandering types" how about just charging for PQ's above and beyond the normal 5. With planning, this would still probably be rarely used, but the cost would help off-set the additional work although never really cover it.

 

You could even limit the PQ's to 250 per. It could be as small as $2.99 or as large as....well..that would be for Jeremy to decide. An added benefit would be for the occasional corrupted PQ. I went through 5 iterations of one of mine trying to get one that was not corrupted. I still wouldn't use it, but could see others that might. Since we would most likely never use it, the price to us would be of little consequence.

 

This would be an additional feature of premium, not meant to replace normal PQ's.

Edited April 11, 2007 by baloo&bd

[+mtn-man]

PQ's already are set at 500, so setting the limit at 250 doesn't seem practical for an "All Caches in a State" PQ.

[+sbell111]

I do think it should be based on a per cache basis if it was done. I am still thinking like a penny a cache. That would discourage running this two or three times a month. I also think the number of people that would do this is small (talking about the "wandering" types, not those that are updating an offline database with this request), so is the need actually there.

If this is for the "wandering types" how about just charging for PQ's above and beyond the normal 5. With planning, this would still probably be rarely used, but the cost would help off-set the additional work although never really cover it.

 

You could even limit the PQ's to 250 per. It could be as small as $2.99 or as large as....well..that would be for Jeremy to decide. An added benefit would be for the occasional corrupted PQ. I went through 5 iterations of one of mine trying to get one that was not corrupted. I still wouldn't use it, but could see others that might. Since we would most likely never use it, the price to us would be of little consequence.

 

This would be an additional feature of premium, not meant to replace normal PQ's.

Building on that idea, TPTB wouldn't really have to change anything. If I wanted more PQs so I could get wandery, all I would have to do is buy an additional one-month subscription for $3.00.

[+VeryLost]

I do think it should be based on a per cache basis if it was done. I am still thinking like a penny a cache. That would discourage running this two or three times a month.

 

Just in case I was unclear, I wasn't thinking of an 'on-demand' state database, where the results were fresh up to the exact second. I was looking more at having the state queries run periodically, say once or thrice a week, and making those files available for download to anyone who wanted to pay. Again, one of the goals was to reduce load on the database server, which an on-demand approach might not accomplish.

[+mtn-man]

[*]Server load on the site for people trying to pull regular queries

Since the topic is "How much would you pay" I assume that a pricing strategy could be worked out to discourage the use of this kind of query except by those that really need it and only for occassional use. It shouldn't have much impact on the regular pocket queries especially if it can reduce the number of users who currently run lots of weekly/daily pocket queries to maintain an off-line database for the same purpose.

Conceding to the first two point, but addressing this one. You have to know that this won't be run occasionally. People already complain about the all finds PQ only running once a week (which I now wish it would run once every six days, but that is another forum topic), so that one is being run regularly. I run mine once a week. There are also topics regarding regular queries not running. I've seen that myself, where my regular weekly local query comes in the next day.

 

I guess I'm just not buying that this is for a once in a while query, which is why I would like to see it cost a penny a cache. If it returns 5,000 caches, it costs you $50.00. The cost will limit its use. Those that want to abuse this will probably pay that though. Who knows. Maybe ten caches per penny is more reasonable, but I think it should cost a premium.

[+mtn-man]

I do think it should be based on a per cache basis if it was done. I am still thinking like a penny a cache. That would discourage running this two or three times a month.

Just in case I was unclear, I wasn't thinking of an 'on-demand' state database, where the results were fresh up to the exact second. I was looking more at having the state queries run periodically, say once or thrice a week, and making those files available for download to anyone who wanted to pay. Again, one of the goals was to reduce load on the database server, which an on-demand approach might not accomplish.

Now, that sounds more reasonable, rather than an "on demand" one. That way it sits and you just download it. You get the same one everyone else gets. That idea I like more, except for the abuse factor.

[+VeryLost]

My question would be, did you pass by more than 500 caches?

 

I've got 500 caches within a 25 mile radius of my house, and I went considerably more than 25 miles on that trip, so yes.

 

So far I haven't seen anything demonstrating that it's a bad idea in general, though.

 

I can give you three. Server load on people accessing the site to look around, server load on the site for people trying to pull regular pocket queries and server load for people trying to log their finds.

 

Those three things boil down to just one answer, and it appears to be based on a faulty premise. The server that generates pocket queries is not the same machine that operates the web user interface. People "looking around" and people "logging their finds" would be unaffected.

 

Generation of normal PQs would almost certainly be unaffected as well, and in theory might/should be improved. Ideally, state-wide GPX files would be scheduled for automatic generation during off-peak hours, and just a few times a week. This, as opposed to multiple people running multiple queries at arbitrary times to generate the same ultimate set of data, 500 waypoints at a time. Multiple queries with several limiting parameters (state, start date, end date) require much more processing resources than a single query with fewer parameters (e.g. state only). By eliminating some of those end-user queries, you reduce server load.

 

Further, remember the "how much would you pay" aspect. Those of us who would use such an offering would be paying additional amounts per file, putting more money in GCs pocket, which in turn could be put towards their ongoing system enhancements.

 

I'm still not seeing a downside.

[+VeryLost]

Now, that sounds more reasonable, rather than an "on demand" one. That way it sits and you just download it. You get the same one everyone else gets. That idea I like more, except for the abuse factor.

 

Yes, exactly! Having it run "on demand" could indeed be an ugly load for the server. If the file is up to date within the past two or three days, that's good enough. I might get a few that have been disabled or archived in the interim, but my DNF rate is high enough anyway that I wouldn't notice the difference.

 

The abuse factor is something I don't quite get, but then, it's not my data, so naturally I don't share GCs potential concerns over it. If the file costs three bucks to download, that's as much as an additional account, so overall I'd say it would be a wash - someone really intent on misusing/stealing the data could manage it for the same price, though it would still take more effort to manually create PQs.

[+baloo&bd]

PQ's already are set at 500, so setting the limit at 250 doesn't seem practical for an "All Caches in a State" PQ.

 

Not for the all states, for those that wander. When they get into an area or know they will be, they would still be able to run a PQ, even if they got over the 5 a day limit for a fee.

[+Markwell]

Some random ramblings here:

 

Here's where I'm really having difficulty in this: Limit some of the criteria instead of trying to get ALL the caches in your download. Are you really going to find a 5/5 puzzle cache requiring research and a 9 mile hike on a wanderlust trip? Limit your criteria to something reasonable that fits your modus operandi. Are you looking for just traditionals? Are you looking for a particular size of container? I would bet that with those limitations you could get a decent PQ of the wander-region on a regular basis to keep loaded in your GPS.

 

But here's the thing I keep trying to get across: you may hit the limit of 2500 caches per day in your PQs. But what does it matter? You've still got 2500 caches in your GPS to search!

 

The real issue then becomes is how the data is truncated. If you do it based on a search center (coordiantes, cache, zip code) it truncates to only the closest 500. If you do it SOLELY by region, it seems to truncate at 500 by date placed. Both of those kill the idea of running out the door GPS in hand and riding wherever the wind takes you.

 

Wouldn't it be nice if we had the option to designate a "random" result of the caches that meet the criteria? Then I could say that I wanted 500 caches within 500 miles that matched all of the criteria that I want, and I wouldn't be limited to only older caches or only caches closest to me. The results would all fit the criteria, but some could be new ones 500 miles away, and some could be old ones 3 blocks away from my home.

 

But for now, limiting the criteria allows you to expand your radius. Choose containers and types and difficulty and terrain based on your search patterns to get more caches into that 2500 per day quota.

 

As far as a reason to say "no" to this? Mtn-man covered much of what I would say regarding abuse. As has been said before - if you really want more data, you can purchase the extra account for $3 for each month (or $30 for a year). Then you've got 5,000 caches PER DAY that you can download, which just about covers all of Illinois.

 

Side note: One thing I wish out of the is that we can do "less than or equal to", "equal to" and "greater than or equal to", but we can't do "between". I'd love to select caches between 2.0 and 4.0 for both difficulty and terrain.

Edited April 11, 2007 by Markwell

[+dirtisgood]

OK, think realistically.

 

Say you pay a penny per cache and get all caches for your state. Say you get a return of 5,000 caches. Say you want this so you can "wander". Your GPS only holds 1,000 caches.

 

If you get a 5,000 cache query, how are you going to get that in your GPS and "wander"?

 

My eXplorist holds significantly more than 1000 caches. I've only used about 12% of the available memory I had on the internal memory and I have about 1600 cahes loaded, several routes, track logs, etc. I have lots more room, and an emply SD card slot. I could theoretically load the entire GC database

 

Don't you have to sort of know where you are going so you can narrow this down to get it into the GPS?

Isn't this what the system does right now?

 

Not really, the system doesn't give me a nice chunk of info in the areas I want, without getting a simple radius filter... GSAK gives me polygon areas, arcs and lines, radius' to NOT include in the search, etc.

 

The request to pay "whatever" for an all caches query isn't so you can "wander". It is for an off site database.

Precisely.

Then it is going to want to be run all the time, so you can have all the logs. That exist right now. It is called http://www.geocaching.com isn't it?

 

Just don't allow it to be run all the time! Set it up internally so that it is run only once per state, per week. (as opposed to once per state, per week, per user) When (and if) the file is requested, and you could set it up that it must be specifically requested, the file is emailed to the user. GSAK is not competition for GC.com, it is a wonderfully brilliant enhancement to an excellent site (GC.com) GSAK is what tipped me over the edge to subscribe to GC.com, and I doubt I'm alone.

 

 

[+GeoCRAt]

From another thread/board:

 

it would be nice if GC would allow "all caches in a state" PQ's.

 

 

I think that's a GREAT idea. But why limit it just to the USA. I would like to see the ability to download all caches in a particular country, say South Africa. I have suggested this before. A good idea, and hopefully something that will be considered.

[+sbell111]

The request to pay "whatever" for an all caches query isn't so you can "wander". It is for an off site database.

Precisely.

The PQ limits are in place to make it more difficult to create off-line databases. Jeremy has been quite clear about this.

[+dirtisgood]

The request to pay "whatever" for an all caches query isn't so you can "wander". It is for an off site database.

Precisely.

The PQ limits are in place to make it more difficult to create off-line databases. Jeremy has been quite clear about this.

I stand corrected, although it doesn't seem very convenient.

[+Mach2003]

I travel quite far usually in a week. I maintain (using poi and waypoints) about 5000 caches in my GPSr. Some days when I travel I have no time for caching, other days I find an extra few hours, and "need" to have quick access to a cache list. I use a large selection of PQ each week to maintain the list in the GPSr (I never realy know where I'll be when I have the time). If a state (or in my case Province), was generated each week, then the "load" on the PQ server would be a LOT less. I wonder how many others generate 20 PQ's a week to get their "state".