Picture Caches and Chain Caches

[+Jake81499]

Scenario . . .

 

Los Cruces New Mexico. I'm headed there to visit. I want to do some caching in a very wide area around the city.

 

I create a pocket query weeks before the trip. I set the parameters for 1000 caches in 500 miles. Ok I don't get 500 miles but I do get a 60 mile circle.

 

I think cool, this will work.

 

So the day before the trip, I run the pocket query again. Now I have a 20 mile circle.

 

Someone has created a sting cache with about 200 caches, a bird picture cache containing around 100 caches and a New Mexico sun sign containing around 100 caches.

 

My expectations of caching a wide area are over. I can't remove those caches using the Cache Type because I LIKE finding micros, smalls or others.

 

I'm writing this because it happened. And it's happened more than once.

 

I'm suggesting that there be two new categories placed in the pocket query cache type section. One for Picture caches, and one for string caches. That way the cachers who still use the pocket queries can deselect those if they don't want to be bothered with them or if they don't want their pocket query filled up by a small area of caches. It would be the cache placers responsibility to designate a sting of caches as a string cache. I can see that locals would have fun with these types of caches, but if I'm just visiting the area - I may not be interested in getting 100 caches in one spot.

 

I know I'll get the usual hammering but string caches are becoming VERY annoying to say the least.

Edited March 20, 2016 by Jake81499

[+Touchstone]

Not the first time this has happened, and not likely to be the last. The Attribute suggestion has been made, and there doesn't appear to be much traction behind the idea.

 

Another approach which I sometimes employ is to pick destinations that interest me and just manually download a handful in the area. It's not usually the case that I cache in between destinations, so it's kind of irrelevant if I have EVERYTHNG.

 

There might be some GSAK related solutions to your problem, but I sympathize with your plight.

[Keystone]

The terms usually associated with this request are "Geo Art" and "Power Trail."

 

There's a manual and a semi-automated solution based on the Ignore List.

 

1. Manually adding each cache to the Ignore List, then running the Pocket Query to exclude items on the Ignore List.

2. Running the Pocket Query, then using a GSAK Filter (filter by owner, filter by cache name, etc.) to select undesired caches, then adding the selected caches in bulk to the Ignore List, using the API interface from GSAK to the bookmark list. Finally, re-run the Pocket Query, excluding caches on the Ignore List.

 

You can also download an entire area to an offline database, and then filter what gets loaded to your GPS or Smartphone for a particular day's worth of caches. Sometimes I feel like a power trail, sometimes I don't. Some Geo Art projects are nice walks in the woods, and some aren't.

[+Bear and Ragged]

PQ by Date Placed...

Most PTs and Art caches in an area have a very similar date.

[+Jake81499]

Ignoring the individual caches is not viable. it wouldn't solve the problem of the shrunken pocket query circle and would take forever. Setting a certain date is not viable because there would be other caches that might be worth going to that may be shut out. If there were a section to ignore the USER NAME of the person setting up the chain cashes on the geocaching website, that would be do-able. Plus it may discourage people from setting up chain caches. Ignoring anything in GSAK wouldn't solve the problem.

 

The best solution would be to add the chain and picture to the cache type list.

[Keystone]

It's true that it would take awhile to ignore 100 caches one at a time by adding them to your Ignore List. But if you download them once into GSAK, then filter on "New Mexico Sun" in the cache title, you can add all 100 to your ignore list with a few keystokes. Then re-run the pocket query (either the same query the next day, or a copy of the query the same day). Total elapsed time from downloading query with "New Mexico Sun" caches to downloading new query without "New Mexico Sun" caches? Under five minutes.

 

I think that's a more viable alternative vs. waiting for new attributes or cache types, especially if you have an upcoming trip planned.

[Pup Patrol]

The terms usually associated with this request are "Geo Art" and "Power Trail."

 

Thank you. That clears it up for me.

 

B.

[+Jake81499]

It's true that it would take awhile to ignore 100 caches one at a time by adding them to your Ignore List. But if you download them once into GSAK, then filter on "New Mexico Sun" in the cache title, you can add all 100 to your ignore list with a few keystokes. Then re-run the pocket query (either the same query the next day, or a copy of the query the same day). Total elapsed time from downloading query with "New Mexico Sun" caches to downloading new query without "New Mexico Sun" caches? Under five minutes.

 

I think that's a more viable alternative vs. waiting for new attributes or cache types, especially if you have an upcoming trip planned.

 

It still wouldn't solve the issue of the shrinking Pocket Query circles. If you had two overlapping circles then suddenly someone adds 300 caches in a chain cache, your circles shrink and you have to create another pocket query to cover the lost area between the two original circles.

 

So how do we petition Geocaching gurus at the top to add this to the pocket query?

[+Jake81499]

Ok, I misread that. Are you saying that gsak will then create an ignored list on geocaching.com?

[Keystone]

It still wouldn't solve the issue of the shrinking Pocket Query circles. If you had two overlapping circles then suddenly someone adds 300 caches in a chain cache, your circles shrink and you have to create another pocket query to cover the lost area between the two original circles.

Not if you exclude those 300 caches via "bulk ignore" or some other method.

 

Ok, I misread that. Are you saying that gsak will then create an ignored list on geocaching.com?

Yes I am. Or rather, GSAK will add dozens or hundreds of caches all at once to your existing Geocaching.com Ignore List. This is done through the API. From the "Geocaching.com Access" menu in GSAK, select "Add to Bookmark List." A list of your bookmarks pops up.* Choose the Ignore List. All caches in your filter are then added to the Ignore List.

 

* Of course, you need to be an authenticated premium member with an unexpired API token, so if you've never used the API, it will take a few more steps than this.

[+Jake81499]

OK that works. I see what your saying. I still want to see it added to the pocket query creation file. The remedy above is a finger in the dike. It doesn't solve the issue of those sudden, or existing chain caches showing up and ruining a Pocket Query. I've seen pocket queries that only cover a 15 mile or less area because of the chain caches imbedded into the area. So you end up making 3 or 4 queries to cover a small area. 3 or 4 queries to cover a 15 mile circle is understandable in a city but not in the middle of a desert. Adding them to the cache type section of the pocket query creation menu would really be useful.

Edited March 20, 2016 by Jake81499

[+Harry Dolphin]

Likewise, there are options that I would like to see in Pocket Queries. I live in North Jersey, and run pocket queries for all caches within sixty-five miles (plus all of New Jersey). I would like to be able to exclude certain counties from my Pocket Queries. Long Island and Staten Island. Nope. I'll probably never go caching again in Kings, Queens, Nassau, Suffolk, The Bronx, or Richmond Counties. It would be nice if I could eliminate them from my Pocket Queries. Keystone's suggestion was to use filters in GSAK to eliminate those counties. That works. But it would be nicer if I could just eliminate them from my PQs.

So, you can ask, but don't expect anything to happen.

Edited March 20, 2016 by Harry Dolphin

[+Jake81499]

Likewise, there are options that I would like to see in Pocket Queries. I live in North Jersey, and run pocket queries for all caches within sixty-five miles (plus all of New Jersey). I would like to be able to exclude certain counties from my Pocket Queries. Long Island and Staten Island. Nope. I'll probably never go caching again in Kings, Queens, Nassau, Suffolk, The Bronx, or Richmond Counties. It would be nice if I could eliminate them from my Pocket Queries. Keystone's suggestion was to use filters in GSAK to eliminate those counties. That works. But it would be nicer if I could just eliminate them from my PQs.

So, you can ask, but don't expect anything to happen.

 

LOL... I think I'd change the names of any caches in those areas to "bait".

 

The chain cache thing used to be fun. But now they are becoming a problem. I had a chain cache between Rawlins Wyo and Casper Wyo but I've deleted most of them after I realized that in other areas they've over run the pocket query abilities. Plus theres a safety issue. I've often wondered how many accidents have been caused by roadside caches and sudden stops. So I just archived them. I don't want to be responsible for such a thing.

 

We need to petition Geocaching to add the ability to ignore them to the Pocket Query creation form.

[Keystone]

We need to petition Geocaching to add the ability to ignore them to the Pocket Query creation form.

As Touchstone noted in the first reply to your thread, this has been requested by others. An attribute addition, in my estimation, stands a greater chance of success than a new cache type. After all, the caches making up the Power Trails and Geo Art designs are one of the other cache types, and the fact that they have strategically placed neighbors doesn't change that. There are letterbox power trails, Geo Art that incorporates Wherigo cartridges, challenge trails -- etc. etc.

 

The difficulty with attributes is enforcing their use. I estimate there'd be little complaint about a Geo Art attribute (maybe an artist's pallette?) but reasonable minds differ on the definition of power trails. I cannot envision reviewers enforcing the use of such an attribute, especially if the cache owner believes that their nice series of caches along a road isn't a "Power Trail" in the ET Highway sense. I don't want to be that guy who has to say "your baby's ugly, so please add the ugly baby attribute and let me know when you've fixed this issue."

[+Jake81499]

We need to petition Geocaching to add the ability to ignore them to the Pocket Query creation form.

As Touchstone noted in the first reply to your thread, this has been requested by others. An attribute addition, in my estimation, stands a greater chance of success than a new cache type. After all, the caches making up the Power Trails and Geo Art designs are one of the other cache types, and the fact that they have strategically placed neighbors doesn't change that. There are letterbox power trails, Geo Art that incorporates Wherigo cartridges, challenge trails -- etc. etc.

 

The difficulty with attributes is enforcing their use. I estimate there'd be little complaint about a Geo Art attribute (maybe an artist's pallette?) but reasonable minds differ on the definition of power trails. I cannot envision reviewers enforcing the use of such an attribute, especially if the cache owner believes that their nice series of caches along a road isn't a "Power Trail" in the ET Highway sense. I don't want to be that guy who has to say "your baby's ugly, so please add the ugly baby attribute and let me know when you've fixed this issue."

 

It's my opinion on this that in many ways these so called Power Trails are ruining the usefulness of the Pocket Query and a big part of why I've slacked off on caching, possibly to the point of not paying my dues this year. If pocket queries no longer work, or if I have to have a dozen to cover what used to take one, then why bother. What good is it to pull a pocket query of a large area just to find a chain of two hundred or so caches following a roadway, all 1/10th of a mile apart, within the parameters of the query you just created. The cache chains are popping up so fast its scary. If you create a query today, check it, looks good, then when you need the query you find a chain right across the middle of it. It's disappointing to say the least.

 

Something needs to be done to give us the power to ignore the chains. Maybe even block caches created by the individuals setting up the chains. if it was set up so we could do the blocking in the pocket query it would most likely be the easiest route. The picture cache I just blocked using the above instructions was called Roadrunner something... Normally these caches all have a single name, set by a single person. It should be easy for the moderators to recognize when a chain cache is being created and ask the owner to change the attribute or type of cache.

 

So at this point the only way to avoid them is to block micro, other and the next size up of cache. That's not fair to those who enjoy those types of caches as well as the large caches.

Edited March 21, 2016 by Jake81499

[Keystone]

It should be easy for the moderators to recognize when a chain cache is being created and ask the owner to change the attribute or type of cache.

For years there was a concept in the Cache Saturation guideline that could be used to block big power trails by a single hider all at once, while allowing caches to develop naturally along a trail with a variety of owners, cache types, containers and hiding styles. It was a miserable failure as a guideline, which is why nowadays "anything over 528 feet" is the test. I don't forsee, under any circumstances, Geocaching HQ asking reviewers to subjectively judge what is or is not a power trail. As an alternative, there could be objective rules like "100 caches by the same owner." Industrious cache owners would immediately figure out that they can hide 99, then have their dog's account hide the next 99, etc.

[+Jake81499]

It should be easy for the moderators to recognize when a chain cache is being created and ask the owner to change the attribute or type of cache.

For years there was a concept in the Cache Saturation guideline that could be used to block big power trails by a single hider all at once, while allowing caches to develop naturally along a trail with a variety of owners, cache types, containers and hiding styles. It was a miserable failure as a guideline, which is why nowadays "anything over 528 feet" is the test. I don't forsee, under any circumstances, Geocaching HQ asking reviewers to subjectively judge what is or is not a power trail. As an alternative, there could be objective rules like "100 caches by the same owner." Industrious cache owners would immediately figure out that they can hide 99, then have their dog's account hide the next 99, etc.

[+Jake81499]

Since the last post I've put 1186 caches on the ignore list. Just chains. One chain was over 500 caches long. It's crazy. I have a GSK file with 295,000 caches in it. I keep it up to date and it extends from the east borders of Texas to North Dakota and all the way over to the California coast with the exception of some of the interior of California. When I originally set that file up I had pretty good overlapping circles across much of that portion of the USA and most of the cities completely covered. Now there are huge gaps, all because of chain caches. I would never say to prevent people from setting such caches. That's their prerogative. We as the users just need some way to block those caches if we so desire.

 

That's all I'm asking and I'm sure there are many others who would ask the same.

Edited March 21, 2016 by Jake81499

[Keystone]

With that sort of reach for your GSAK database, overlapping circles are terribly, terribly inefficient. I'd look into date-ranged queries by state for the states you cover generally, or around cities or regions in states where you don't need 100% coverage. Back the power trails out of those queries and you will be all set.

 

I maintain up-to-date coverage for every cache in 21 states and three foregin countries, using GSAK databases totalling more than 300,000 caches, plus 50,000 more caches in regional coverage for a number of other areas (Vegas, Southern California, New Orleans and other tourist destinations I enjoy returning to). Date ranged queries is definitely the way to go.

[+niraD]

* Of course, you need to be an authenticated premium member with an unexpired API token, so if you've never used the API, it will take a few more steps than this.

You also need to be using a system that can install and run MS Windows software.

[+narcissa]

Our area has been badly damaged by these repetitive chains of caches, so we run several highly specific pocket queries for the caches we want to find and layer them over each other.

[+jellis]

Since the last post I've put 1186 caches on the ignore list. Just chains. One chain was over 500 caches long. It's crazy. I have a GSK file with 295,000 caches in it. I keep it up to date and it extends from the east borders of Texas to North Dakota and all the way over to the California coast with the exception of some of the interior of California. When I originally set that file up I had pretty good overlapping circles across much of that portion of the USA and most of the cities completely covered. Now there are huge gaps, all because of chain caches. I would never say to prevent people from setting such caches. That's their prerogative. We as the users just need some way to block those caches if we so desire.

 

That's all I'm asking and I'm sure there are many others who would ask the same.

Are you going to find 295k caches on your trip? If it were me I would just do a PQ route on the roads I will be going on, and add any special caches manually. I would delete any that would take too much time like high terrain, ones that have a lot of DNFs by COs not active, ones in the most busy sections of the cities, etc. Plan which caches you really want to find. It also depends on how long you plan to stay in each area.

Like our San Jose, I live about 25 miles away and been going there many times over the 9 yrs and I haven't made a dent.

Just me I don't like to over populate my GPS with caches I clearly am not going to go find.

Filtering in GSAK is the best way to go.

[knowschad]

The terms usually associated with this request are "Geo Art" and "Power Trail."

 

There's a manual and a semi-automated solution based on the Ignore List.

 

1. Manually adding each cache to the Ignore List, then running the Pocket Query to exclude items on the Ignore List.

2. Running the Pocket Query, then using a GSAK Filter (filter by owner, filter by cache name, etc.) to select undesired caches, then adding the selected caches in bulk to the Ignore List, using the API interface from GSAK to the bookmark list. Finally, re-run the Pocket Query, excluding caches on the Ignore List.

 

You can also download an entire area to an offline database, and then filter what gets loaded to your GPS or Smartphone for a particular day's worth of caches. Sometimes I feel like a power trail, sometimes I don't. Some Geo Art projects are nice walks in the woods, and some aren't.

 

Wouldn't it be nice if by 2016, Groundspeak had finally listed to the GSAK users and added some of that functionality to the website and apps?

[+hzoi]

If you're not interested in the power trails, there are still plenty of great caches to be had around Las Cruces, especially around the Organ Mountains.

 

It's a little outside the Las Cruces area, but if you like exploring ghost towns, I recommend you hit Can You? 2.0 and the caches in the surrounding area.

 

I hope you enjoy your visit.

[+Jake81499]

Our area has been badly damaged by these repetitive chains of caches, so we run several highly specific pocket queries for the caches we want to find and layer them over each other.

 

Yea, it's my opinion that power caches have nearly ruined geocaching for several reasons. One, you have to make more pocket queries to cover the same area that's infected. Two, the armchair cacher just has to find a power cache on his map and claim them all (and I've seen it done). Three, if someone wants to put a legitimate cache in the area they can't because it's already swamped. Four, Route pocket queries are basically ruined any time theres a chain placed along one of them. And I could go on and on. It's really caused me to back off on the caching the last couple years. It's obvious the geocaching top gurus aren't going to do anything to help those of us that are annoyed by them. Just a new rule on chains and pictures with an opt out box in the build a pocket query section is all that's needed. But it'll never happen. I guess those yearly dues don't mean all that much.

 

Oh, I do keep a maximum number of caches up to date in my gps, over 250,000 of them. The reason is because if I get tired while traveling I can always stop to find a cache. There's not always phone data to find them with my phone. It used to be kind of fun to pick up the gps and find a cache two miles ahead. But I find more and more blank areas all because of power caches. Complete bummer. I'm a traveler, explorer you might say, and I ever know where I'm going. I especially like new mexico and I'm trying to retire there.

Edited March 29, 2016 by Jake81499

[+narcissa]

Our area has been badly damaged by these repetitive chains of caches, so we run several highly specific pocket queries for the caches we want to find and layer them over each other.

 

Yea, it's my opinion that power caches have nearly ruined geocaching for several reasons. One, you have to make more pocket queries to cover the same area that's infected. Two, the armchair cacher just has to find a power cache on his map and claim them all (and I've seen it done). Three, if someone wants to put a legitimate cache in the area they can't because it's already swamped. Four, Route pocket queries are basically ruined any time theres a chain placed along one of them. And I could go on and on. It's really caused me to back off on the caching the last couple years. It's obvious the geocaching top gurus aren't going to do anything to help those of us that are annoyed by them. Just a new rule on chains and pictures with an opt out box in the build a pocket query section is all that's needed. But it'll never happen. I guess those yearly dues don't mean all that much.

 

Oh, I do keep a maximum number of caches up to date in my gps, over 250,000 of them. The reason is because if I get tired while traveling I can always stop to find a cache. There's not always phone data to find them with my phone. It used to be kind of fun to pick up the gps and find a cache two miles ahead. But I find more and more blank areas all because of power caches. Complete bummer. I'm a traveler, explorer you might say, and I ever know where I'm going. I especially like new mexico and I'm trying to retire there.

 

There are still lots of good caches out there, it's just harder to wade through the search results than it used to be. "Armchair" cachers don't really affect me except for the rare occasion that they accidently log one of my caches, in which case I delete the find. When travelling we run pocket queries for Earthcaches, multis, virtuals, letterboxes and web cams. We don't bother with traditionals unless we're going to be in one place for a while and we can do a more specific pocket query for an area. It's just not worth the hassle.

[+Jake81499]

 

There are still lots of good caches out there, it's just harder to wade through the search results than it used to be. "Armchair" cachers don't really affect me except for the rare occasion that they accidently log one of my caches, in which case I delete the find. When travelling we run pocket queries for Earthcaches, multis, virtuals, letterboxes and web cams. We don't bother with traditionals unless we're going to be in one place for a while and we can do a more specific pocket query for an area. It's just not worth the hassle.

 

I've considered changing the size of cache and dropping micro but it won't really help. Too many chains are of multiple sizes. I only select traditional unless it's something close by home. If I'm out of the bike I don't want to be tracing all over the country trying to find a multi. I don't see how anyone could maintain a 1000+ cache chain cache. I had one set up with only thirty caches between Rawlins Wyo and Casper Wyo for a while before I saw how much of a nuisance it was, I've since archived most of them. It wasn't one of those 1/10th of a mile chains though, it was 30 caches in 100 miles. It was still a nuisance. I decided it was unsafe also. I couldn't imagine what I would feel like if some cacher slammed on his brakes to pull off on a turn out and got real ended by a 18 wheeler.

Edited March 29, 2016 by Jake81499

[+The Jester]

We need to petition Geocaching to add the ability to ignore them to the Pocket Query creation form.

As Touchstone noted in the first reply to your thread, this has been requested by others. An attribute addition, in my estimation, stands a greater chance of success than a new cache type. After all, the caches making up the Power Trails and Geo Art designs are one of the other cache types, and the fact that they have strategically placed neighbors doesn't change that. There are letterbox power trails, Geo Art that incorporates Wherigo cartridges, challenge trails -- etc. etc.

 

The difficulty with attributes is enforcing their use. I estimate there'd be little complaint about a Geo Art attribute (maybe an artist's pallette?) but reasonable minds differ on the definition of power trails. I cannot envision reviewers enforcing the use of such an attribute, especially if the cache owner believes that their nice series of caches along a road isn't a "Power Trail" in the ET Highway sense. I don't want to be that guy who has to say "your baby's ugly, so please add the ugly baby attribute and let me know when you've fixed this issue."

 

It's my opinion on this that in many ways these so called Power Trails are ruining the usefulness of the Pocket Query and a big part of why I've slacked off on caching, possibly to the point of not paying my dues this year. If pocket queries no longer work, or if I have to have a dozen to cover what used to take one, then why bother. What good is it to pull a pocket query of a large area just to find a chain of two hundred or so caches following a roadway, all 1/10th of a mile apart, within the parameters of the query you just created. The cache chains are popping up so fast its scary. If you create a query today, check it, looks good, then when you need the query you find a chain right across the middle of it. It's disappointing to say the least.

 

Something needs to be done to give us the power to ignore the chains. Maybe even block caches created by the individuals setting up the chains. if it was set up so we could do the blocking in the pocket query it would most likely be the easiest route. The picture cache I just blocked using the above instructions was called Roadrunner something... Normally these caches all have a single name, set by a single person. It should be easy for the moderators to recognize when a chain cache is being created and ask the owner to change the attribute or type of cache.

 

So at this point the only way to avoid them is to block micro, other and the next size up of cache. That's not fair to those who enjoy those types of caches as well as the large caches.

Some of the function you want is available using the API GetCaches - ignoring by CO is easy. You can get up to 6000 caches a day with full info, and 10,000 a day with limited data (which can then be refreshed later to full daya if you want, which also counts against the per day limits). You're a GSAK user, so check it out (other API Parner programs have the same functions).

[+Jake81499]

Some of the function you want is available using the API GetCaches - ignoring by CO is easy. You can get up to 6000 caches a day with full info, and 10,000 a day with limited data (which can then be refreshed later to full daya if you want, which also counts against the per day limits). You're a GSAK user, so check it out (other API Parner programs have the same functions).

 

Yes I know that. It gives you the option of ignoring by user name. That is useful. But I'm looking at over 250,000 caches in gsak. I use the pocket query system. An ignore user name section would be useful in the pocket query. Take a look at mondou2 (I think) in eastern Colorado and look around DIA in Denver. It's chain after chain, most of which are owned by mondou2. Ignoring that user name in the pocket query would be the very best way to go but it would also eliminate his more legitimate caches which may not be acceptable. I know this is a dead subject because the higher ups don't think its an issue. But it is. It's quickly making the pocket query system useless. I have around 300 pocket querys, many of them have been shrunk considerably because of chain and picture caches. There needs to be something added to the pocket query system so we can ignore those caches completely. They need to be designated as power or chain caches so those of us who are not interested in allowing them to corrupt our pocket queries can just block them out.

[+HHL]

[....] I use the pocket query system. An ignore user name section would be useful in the pocket query. Take a look at mondou2 (I think) in eastern Colorado and look around DIA in Denver. It's chain after chain, most of which are owned by mondou2. Ignoring that user name in the pocket query would be the very best way to go [...]

 

You may find this macro useful as it lets you bulk uploading caches to your ignore list. Then exempt ignored caches from your PQs.

 

 

Frohes Jagen

Hans

[+Walts Hunting]

Likewise, there are options that I would like to see in Pocket Queries. I live in North Jersey, and run pocket queries for all caches within sixty-five miles (plus all of New Jersey). I would like to be able to exclude certain counties from my Pocket Queries. Long Island and Staten Island. Nope. I'll probably never go caching again in Kings, Queens, Nassau, Suffolk, The Bronx, or Richmond Counties. It would be nice if I could eliminate them from my Pocket Queries. Keystone's suggestion was to use filters in GSAK to eliminate those counties. That works. But it would be nicer if I could just eliminate them from my PQs.

So, you can ask, but don't expect anything to happen.

GS doesn't know what counties the caches are in just country and state.

[+TerraViators]

Industrious cache owners would immediately figure out that they can hide 99, then have their dog's account hide the next 99, etc.

 

Aren't many reviewers dogs?

[+Jake81499]

Industrious cache owners would immediately figure out that they can hide 99, then have their dog's account hide the next 99, etc.

 

Even if there are cheaters (And I've seen that there are many in the form of armchair cachers) placing an exemption in the pocket query creation form would greatly reduce the number of chain caches that a person had to put up with in the downloaded query. Addition of a 'block by user name' in the query could then be used to block all the persons caches who is cheating.

 

One of the big problems I've seen with any of the suggestions that people have made in this thread is many people use the pocket query's as a 'sudden' download. The person decides out of the blue to go on a road trip out in the country a hundred miles away. He builds a pocket query for that area expecting a wide circle in which he can pick up a couple caches while exploring. He runs the query just to discover that there is a chain of 1000 caches smack dab in the middle of the area he wanted. So he ends up either making another query further out away from the chain or maybe several query's further away from the chain. Then he finds even more chains which make all his work null and void. People are assuming that everyone does their caching the same way, uses the same tools, uses their iPhone for caching. They are assuming we will block all the micros to avoid a chain. They assume we don't mind using a macro in GSAK to block chains and then only get ten or so caches out of the 1000 we wanted.

 

What needs to happen is a little clicky box placed in the pocket query creation and the cache submission pages which says 'Power Cache' so that we can choose if we want to download them and the creator can choose that it is a power cache. This may not help the current contamination with Power Caches but it might help the future.

[Keystone]

What needs to happen is a little clicky box placed in the pocket query creation and the cache submission pages which says 'Power Cache' so that we can choose if we want to download them and the creator can choose that it is a power cache. This may not help the current contamination with Power Caches but it might help the future.

Who is in charge of applying the "Your Baby Is Ugly" attribute, and how is its usage to be enforced consistently worldwide?

[+Jake81499]

What needs to happen is a little clicky box placed in the pocket query creation and the cache submission pages which says 'Power Cache' so that we can choose if we want to download them and the creator can choose that it is a power cache. This may not help the current contamination with Power Caches but it might help the future.

Who is in charge of applying the "Your Baby Is Ugly" attribute, and how is its usage to be enforced consistently worldwide?

 

Whats so hard about it? Who is to say some clown isn't going to post a micro as a large? Who's to say someone isn't going to use the Horses Welcome attribute in the middle of Denver? What if someone says it's a traditional and it turns out to be a multi cache? We can play what if all day long. We need an attribute for Power Cache. Then if they do it wrong they need to be called on it. That's what moderators and reviewers are for. It's not all that hard and most cachers are honest enough to post them as a Power Cache.

Edited April 8, 2016 by Jake81499

[+L0ne.R]

What needs to happen is a little clicky box placed in the pocket query creation and the cache submission pages which says 'Power Cache' so that we can choose if we want to download them and the creator can choose that it is a power cache. This may not help the current contamination with Power Caches but it might help the future.

Who is in charge of applying the "Your Baby Is Ugly" attribute, and how is its usage to be enforced consistently worldwide?

 

Whats so hard about it? Who is to say some clown isn't going to post a micro as a large? Who's to say someone isn't going to use the Horses Welcome attribute in the middle of Denver? What if someone says it's a traditional and it turns out to be a multi cache? We can play what if all day long. We need an attribute for Power Cache. Then if they do it wrong they need to be called on it. That's what moderators and reviewers are for. It's not all that hard and most cachers are honest enough to post them as a Power Cache.

I agree. And I think there will be way more peer pressure on the guy who doesn't use the attribute (or checkbox) for his PT, then on the guy who uses the Horses Welcome attribute in the middle of Denver.

[+Jake81499]

What needs to happen is a little clicky box placed in the pocket query creation and the cache submission pages which says 'Power Cache' so that we can choose if we want to download them and the creator can choose that it is a power cache. This may not help the current contamination with Power Caches but it might help the future.

Who is in charge of applying the "Your Baby Is Ugly" attribute, and how is its usage to be enforced consistently worldwide?

 

Whats so hard about it? Who is to say some clown isn't going to post a micro as a large? Who's to say someone isn't going to use the Horses Welcome attribute in the middle of Denver? What if someone says it's a traditional and it turns out to be a multi cache? We can play what if all day long. We need an attribute for Power Cache. Then if they do it wrong they need to be called on it. That's what moderators and reviewers are for. It's not all that hard and most cachers are honest enough to post them as a Power Cache.

I agree. And I think there will be way more peer pressure on the guy who doesn't use the attribute (or checkbox) for his PT, then on the guy who uses the Horses Welcome attribute in the middle of Denver.

 

Looks like they're trying to let this die. Not gonna happen. Something needs to be done.

[+cerberus1]

The terms usually associated with this request are "Geo Art" and "Power Trail."

Thanks for that.

[+narcissa]

To me, the major benefit of separating these caches is that the expectations of owner maintenance are so different between a true traditional geocache and a power trail cache.

 

If there was a power trail type or attribute, then hold people accountable for how they list their cache. A traditional geocache that isn't part of a power trail should be well-maintained by the owner. Throw-downs are not acceptable, finders need to sign the log, the container should be in good shape. If someone insists that their straight line of 356360562 films cans isn't a power trail, hold them accountable for the integrity of each and every cache. If someone wants to put out a power trail, and they list it as such, then we treat those caches accordingly and the expectations change: it's okay to toss a pill bottle out the window as you drive/bike past, it's okay not to log them, the owner never has to maintain them because the community does.

 

If Groundspeak doesn't want to explicitly define those expectations as such, then perhaps they need to reconsider the situation they've created by allowing these power trails to exist in the first place.

[+Mudfrog]

We need to petition Geocaching to add the ability to ignore them to the Pocket Query creation form.

As Touchstone noted in the first reply to your thread, this has been requested by others. An attribute addition, in my estimation, stands a greater chance of success than a new cache type. After all, the caches making up the Power Trails and Geo Art designs are one of the other cache types, and the fact that they have strategically placed neighbors doesn't change that. There are letterbox power trails, Geo Art that incorporates Wherigo cartridges, challenge trails -- etc. etc.

 

The difficulty with attributes is enforcing their use. I estimate there'd be little complaint about a Geo Art attribute (maybe an artist's pallette?) but reasonable minds differ on the definition of power trails. I cannot envision reviewers enforcing the use of such an attribute, especially if the cache owner believes that their nice series of caches along a road isn't a "Power Trail" in the ET Highway sense. I don't want to be that guy who has to say "your baby's ugly, so please add the ugly baby attribute and let me know when you've fixed this issue."

Groundspeak has the say so here and it wouldn't be difficult at all for them to define a power trail. For example, let's say 20 caches spaced out .1 miles from each other along side of a road. Yes, there could be other things that come into play but for the most part, this seems fairly simple.

 

Whether they're a whole nother cache type or they have a PT attribute doesn't make much difference. Just so long as they can be filtered in or out of a pocket query. This would be helpful for both, people looking for them and for those who aren't.

Edited April 13, 2016 by Mudfrog

[+cerberus1]

Groundspeak has the say so here and it wouldn't be difficult at all for them to define a power trail. For example, let's say 20 caches spaced out .1 miles from each other along side of a road.

Nearby, a couple placed ten or so caches on a wide gamelands trail (every .1).

A few weeks later, a different cacher placed another dozen or so, extending that trail.

And so on, and so on...

There's now around forty on a five mile stretch.

 

I'd think it'd be a pain-in-the-can to define a power trail.

What if each person that visited extended it by one?

- Did he add to a "power trail", or simply place a cache?

Should the single placer be forced to add a PT attribute, even though his intention is to simply place one hide?

 

I don't think Groundspeak would want to get involved in this, since just here in the forums, many have different opinions on what a PT is.

What does the other coupla million think?

[+Jake81499]

Easy, define it as any caches placed in any line of greater than 10 caches 1/10th to 3/10ths of a mile apart by the same username. I can see there might be difficulty when that users significant other or even another cacher places additional caches to extend that trail. There is an example of that somewhere close to the South Dakota eastern border (I think) in which several cachers have saturated the area roads with caches. The advantage of that area is they were all the same basic cache name. A reviewer should be able to catch that and then inform the placers that they need to be designated as a power cache. In the above case I was able to place most of them in the ignore list (which is now excessively huge).

 

My personal feeling about power caches? How the heck are they going to maintain all those? There are chains out there over a thousand caches, all 1/10th of a mile apart. Ridicules and it takes the fun out of things. I'm not impressed when a person says they found 10,000 caches found. Oh, how many of those are power caches? All of them.

 

Not to mention they are the armchair cacher's heaven.

 

And as far as adding caches later one buy one, peer pressure would be enormous. But there could a bonus if 1 out of 5 caches were not called a power cache. People who actually want to find a cache in that area would have something to find even though they don't want to be bothered by the power cache itself. Add in the description that the cache in question as actually a part of a larger power cache. That would give the cacher going to the area the option of downloading the entire power cache if they read the description of the cache before going to the area.

Edited April 14, 2016 by Jake81499

[+dragonfly229]

I agree with Jake81499. I really have zero interest in finding any of these caches. It seems a little like Groundhog Day - finding the same thing over and over and over again. Where is the fun/challenge/excitement in that? I plan to block them by cacher - if someone likes to place caches that way, I don't want to bother with any of their hides, even if they might be different (which I doubt). Sure, I need to bump my numbers up, but I would rather do it with real caches that are interesting in their own way.

 

Come on Groundspeak - find a way to categorize these so we can chose not to bother with them.

[+Jake81499]

I agree with Jake81499. I really have zero interest in finding any of these caches. It seems a little like Groundhog Day - finding the same thing over and over and over again. Where is the fun/challenge/excitement in that? I plan to block them by cacher - if someone likes to place caches that way, I don't want to bother with any of their hides, even if they might be different (which I doubt). Sure, I need to bump my numbers up, but I would rather do it with real caches that are interesting in their own way.

 

Come on Groundspeak - find a way to categorize these so we can chose not to bother with them.

 

I'm not sure if you can block them by cacher. It probably can be done in GSAK but the way I read it is the pocket query will still have all that users caches, they are just not added to the GSAK database. So you end up not getting the 1000 caches you want.

 

But overall I agree. If someone just has to place power caches, I'm to the point where I would gladly block all their caches. But again, the user needs to be blocked via the geocaching website.

Edited April 14, 2016 by Jake81499

[+on4bam]

I'm not sure if you can block them by cacher. It probably can be done in GSAK but the way I read it is the pocket query will still have all that users caches, they are just not added to the GSAK database. So you end up not getting the 1000 caches you want.

 

You can do this in GSAK and all you have to do is make sure the CO's caches are in a database just once. Filter caches by xxxx and via API "add to bookmark list", then choose ignore list. Next PQ the ignored caches will no longer show up in your PQs. In case a CO places new caches you just have to repeat the process.

[+The Jester]

I agree with Jake81499. I really have zero interest in finding any of these caches. It seems a little like Groundhog Day - finding the same thing over and over and over again. Where is the fun/challenge/excitement in that? I plan to block them by cacher - if someone likes to place caches that way, I don't want to bother with any of their hides, even if they might be different (which I doubt). Sure, I need to bump my numbers up, but I would rather do it with real caches that are interesting in their own way.

 

Come on Groundspeak - find a way to categorize these so we can chose not to bother with them.

I've found a few caches down around the ET power trail that were hidden by the same CO that were quite good. I think it was places/things they found while scouting/placing the PT. So not all PT CO's have only PT-type hides.

 

I'm not sure if you can block them by cacher. It probably can be done in GSAK but the way I read it is the pocket query will still have all that users caches, they are just not added to the GSAK database. So you end up not getting the 1000 caches you want.

 

But overall I agree. If someone just has to place power caches, I'm to the point where I would gladly block all their caches. But again, the user needs to be blocked via the geocaching website.

It's not a perfect soulution, but the Groundspeak API does a lot of what you want (ignore by User Name). But, you need to use a API Partner third party software to get that functionality.

 

It's too bad the PQ genrator doesn't use API calls (thereby giving the same functionality) so that those that use PQ files to directly load GPSr's (or other devices) could have/not have the caches they want. I wouldn't think it's that hard to set up.

[+Jake81499]

I'm not sure if you can block them by cacher. It probably can be done in GSAK but the way I read it is the pocket query will still have all that users caches, they are just not added to the GSAK database. So you end up not getting the 1000 caches you want.

 

You can do this in GSAK and all you have to do is make sure the CO's caches are in a database just once. Filter caches by xxxx and via API "add to bookmark list", then choose ignore list. Next PQ the ignored caches will no longer show up in your PQs. In case a CO places new caches you just have to repeat the process.

 

Already doing that. My ignore list is huge. It doesn't work for ignoring the user, just the caches. Every pocket query has to be checked. Excessively time consuming. There's so many arguments that can be and for and against power caches that we could keep this up forever. I'm not against them, I just want a way to filter them out. It would be easy to put this into the pocket query creation filters and write some rules around power caches. So, this will go on and on, and probably ignored. We need either the power cache filter or the block caches by user name ability.

[+on4bam]

 

Already doing that. My ignore list is huge. It doesn't work for ignoring the user, just the caches. Every pocket query has to be checked. Excessively time consuming.

 

It DOES work.

You're correct that you're ignoring caches not CO's but if you bulk add the filtered caches (by that CO) to the ignore list they will not show up in the PQs. No need to check PQs.

 

As for time consuming, it takes less than 5 minutes and works until the CO puts out new caches. At that time you just( repeat the process.

[+Jake81499]

 

Already doing that. My ignore list is huge. It doesn't work for ignoring the user, just the caches. Every pocket query has to be checked. Excessively time consuming.

 

It DOES work.

You're correct that you're ignoring caches not CO's but if you bulk add the filtered caches (by that CO) to the ignore list they will not show up in the PQs. No need to check PQs.

 

As for time consuming, it takes less than 5 minutes and works until the CO puts out new caches. At that time you just( repeat the process.

 

I'm not finding anywhere that you can block the caches by user name that also adds the user to the ignore list. We really shouldn't have to do repeat the process ever, just ignore the user permanantly. Why should we have to use the ignore list anyhow. Right now my ignore list shows about 10,000 caches, all power caches. What we need is something in the pocket query creation that says Power Cache. We have large, we have small, we have traditional, we have multi. Why not power? There's rules for traditional, there's rules for multi. Why not power? It would be so easy to do and nobody's willing to do it.

 

And it's horribly time consuming to ignore caches. 5 minutes my butt. If you go from start to finish, create the query, check the query on geocaching.com, download the query to GSAK, locates or sort the caches to be ignored in GSAK, create the ignore list in GSAK. THEN, since your pocket query was trashed by power caches, you have to start over again AND can't download the same query until the following day. Yea, it's time consuming especially if you have pocket queries that are already created and that's the easy part if you only run 1000 caches in your GPS. What about those of us who have hundreds of pre-created pocket queries that we download on a regular basis and run the full boat in our GPS's all the time. It can take GSAK up to an hour to export a map of 255,410 caches.

 

I feel sorry for the guy who creates a pocket query two weeks before he needs it, say planning for a vacation, and then downloads it 10 minutes before he hits the road. Who knows how many power caches have been added which end up totally ruining his caching plans.

 

And yes, I run the full boat in my GPS. I used to be extremely active in caching. I ride a motorcycle and don't make plans on where I go. Much of the time there is no data service on my phone so I can't rely on that for caching. So I keep every traditional cache in the GPS from the east borders of Texas to North Dakota and all the way to the Pacific coast. There are currently as of today, 255,410, before I run the Status Check in GSAK. It's a daily ritual of updating the cache list in GSAK but GSAK makes it extremely easy to keep up. It takes 39 days to download my entire pocket query list (10 every day) and I've had to add more queries because of the power cache problem. The only thing I have to do is keep the scheduled pocket query download list up to date 6 days in advance and tell GSAK what to do. I download the GSAK database to the GPS about twice a week. Since I saw how many armchair cachers there are and the power cache problem became more severe I have really slowed down on the caching to almost not at all. But I still keep the GPS up to date. People might say 'Oh that sounds terribly inefficient', but I like it.

Edited April 15, 2016 by Jake81499

[Keystone]

And it's horribly time consuming to ignore caches. 5 minutes my butt. If you go from start to finish, create the query, check the query on geocaching.com, download the query to GSAK, locates or sort the caches to be ignored in GSAK, create the ignore list in GSAK. THEN, since your pocket query was trashed by power caches, you have to start over again AND can't download the same query until the following day. Yea, it's time consuming especially if you have pocket queries that are already created and that's the easy part if you only run 1000 caches in your GPS. What about those of us who have hundreds of pre-created pocket queries that we download on a regular basis and run the full boat in our GPS's all the time. It can take GSAK up to an hour to export a map of 255,410 caches.

You are still not understanding on4bam's suggestion. What you described in the quote above is not what on4bam is recommending. I recommend reading more carefully and politely asking questions rather than dismissing someone who's trying to help you with phrases like "5 minutes my butt." It DOES take less than 5 minutes using the GSAK and API method.

 

Perhaps on4bam might be willing to post some screenshots?