Picture Caches and Chain Caches

[+Walts Hunting]

Actually 5 minutes is way more time than needed. I have done this in the past and just ran a test. Using GSAK API Get Caches into an empty DB using the Light option and putting the CO I wanted to ignore in the Owned By Box. Results in about a minute then Add to Bookmark list would take less than a minute and a half and done. Your procedure of PQ sort/filter is the wrong path and very time consuming.

 

It is true that someone could have put another power trail but that gets less and less likely as an area gets saturated.

 

In the time it took you to write the previous post you could have done it three times.

[+on4bam]

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.

 

Well, there's the highway and then there's the scenic route. Unfortunately your scenic route is not as efficient as my highway route

 

1. You don't need to get the caches to ignore via PQ. Use "get geocaches" via API and select "ignored CO name" Using "light" format you can get 10000/day.

2. You don't have to create an ignore list in GSAK, once ignored caches/CO's are filtered add them to the ignorelist via API.

3. Even if you work by running and downloading PQs, you don't have to run the PQ again, you can or download the file again (it's there for a week) or change the "delete downloaded PQ" setting in GSAK.

 

Looks like you have to read up on GSAK to use it more efficiently

Even after almost 10 years of GSAK use I still learn new things about it, install new macros to fine tune my workflow.

[+L0ne.R]

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?

 

Yes screenshots would be very helpful. I have on occasion downloaded GSAK, only to get discouraged by macros and give up. Maybe screenshots would help get me to try again.

[+HHL]

[...]

Yes screenshots would be very helpful. I have on occasion downloaded GSAK, only to get discouraged by macros and give up. Maybe screenshots would help get me to try again.

 

There are tons of screenshots in GSAK's help file.

 

Hans

[+Jake81499]

ok, so show me how to completely block an individual user who is posting power caches without reducing the number of useable traditional caches requested in the pocket query.

[+Jake81499]

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.

 

Well, there's the highway and then there's the scenic route. Unfortunately your scenic route is not as efficient as my highway route

 

1. You don't need to get the caches to ignore via PQ. Use "get geocaches" via API and select "ignored CO name" Using "light" format you can get 10000/day.

2. You don't have to create an ignore list in GSAK, once ignored caches/CO's are filtered add them to the ignorelist via API.

3. Even if you work by running and downloading PQs, you don't have to run the PQ again, you can or download the file again (it's there for a week) or change the "delete downloaded PQ" setting in GSAK.

 

Looks like you have to read up on GSAK to use it more efficiently

Even after almost 10 years of GSAK use I still learn new things about it, install new macros to fine tune my workflow.

 

I used to do the API, it doesn't work out all that well for what I'm doing. They're probly aren't a bunch of people who keep their GPS filled to 250,000+ caches. API works great for small numbers. When you get this many things get more complicated. I like it like this, they're always there no mater where I go. Now if we could only fix the Power Cache problem.

Edited April 15, 2016 by Jake81499

[+HHL]

ok, so show me how to completely block an individual user who is posting power caches without reducing the number of useable traditional caches requested in the pocket query.

 

Read that again

[+on4bam]

I used to do the API, it doesn't work out all that well for what I'm doing. They're probly aren't a bunch of people who keep their GPS filled to 250,000+ caches. API works great for small numbers. When you get this many things get more complicated. I like it like this, they're always there no mater where I go. Now if we could only fix the Power Cache problem.

 

It's been explained (more than once). I prepared some caches for tomorrow, have things to do Sunday so if this thread is still active on Monday I might give it another try but not now

[+Jake81499]

this isn't about how a person geocaches or uses gsak. Everybody has a different way of doing everything. I could easily post pictures to explain why it would be more more difficult and more time consuming for me to do it some of the ways that others do it and maybe I'm doing it more difficult than what I could be doing it. It's about there being no way to block power caches in the pocket query setup. It would be ridiculously easy to add another cache type and set up some rules for power caches. It's been explained how it can be done not only in this post but in others as well. We need a cache type addition in the pocket query setup.

[Keystone]

It would be ridiculously easy to add another cache type and set up some rules for power caches.

Ummm, no it wouldn't. Saying it would be easy doesn't make it so.

 

As I stated in an earlier post, a cache attribute is a more realistic goal, provided that reviewers are not asked to enforce a subjective or arbitrary definition and insist on the presence of an attribute.

 

In the meantime, since this is a general geocaching discussion thread and not a feature request, the suggested workarounds are certainly worthy of more discussion.

[+Jake81499]

Sorry, I'm respectfully not seeing anything hard about it. It's just a matter or putting their minds to it and finding a fix. And I agree an attribute would also work. Anything to help us eliminate these caches from the pocket queries. Most of the remedies above work but mostly on a limited basis and I'm using a couple. I'm experimenting with the download by state. It looks promising IF it downloads every cache in the state. If it only downloads 1000 then it's limited also. If downloading by state would download all the caches in that state then the power cache argument would almost be mute.

[+on4bam]

Sorry, I'm respectfully not seeing anything hard about it. It's just a matter or putting their minds to it and finding a fix. And I agree an attribute would also work. Anything to help us eliminate these caches from the pocket queries. Most of the remedies above work but mostly on a limited basis and I'm using a couple. I'm experimenting with the download by state. It looks promising IF it downloads every cache in the state. If it only downloads 1000 then it's limited also. If downloading by state would download all the caches in that state then the power cache argument would almost be mute.

 

I'd still say learn a bit more about GSAK. Via the API you can get 6000 full/1000 light caches to import. Filter by country/state/type.... whatever

 

Filter out power trails? no problem, there a macro (cacheseries.gsk) for that. It will filter caches with the same name (select common characters and minimum #of caches). You can automatically have the userflag set for them and bulk add them (API again) to your ignore list.

[+Jake81499]

Sorry, I'm respectfully not seeing anything hard about it. It's just a matter or putting their minds to it and finding a fix. And I agree an attribute would also work. Anything to help us eliminate these caches from the pocket queries. Most of the remedies above work but mostly on a limited basis and I'm using a couple. I'm experimenting with the download by state. It looks promising IF it downloads every cache in the state. If it only downloads 1000 then it's limited also. If downloading by state would download all the caches in that state then the power cache argument would almost be mute.

 

I'd still say learn a bit more about GSAK. Via the API you can get 6000 full/1000 light caches to import. Filter by country/state/type.... whatever

 

Filter out power trails? no problem, there a macro (cacheseries.gsk) for that. It will filter caches with the same name (select common characters and minimum #of caches). You can automatically have the userflag set for them and bulk add them (API again) to your ignore list.

 

Yea I've used the API for over a year before I started just downloading all of them via the pocket queries. API is too limited. I use the Status check to filter out archived caches and get recent logs to help keep the others up to date. I didn't know about the macro, will look at that this week. I just tried pocket queries by state and that's a dead end. Another thread in the forums is pushing for allowing more caches in the queries and I can see where that would solve the problem if the States query would download the entire state rather than only a select 1000. I'm going to experiment with the states over a week long test though. If it pulls a different 1000 each time it might still be useful. The problem of power trails should have been nipped in the bud a long time ago.

Edited April 17, 2016 by Jake81499

[+on4bam]

Yea I've used the API for over a year before I started just downloading all of them via the pocket queries. API is too limited. I use the Status check to filter out archived caches and get recent logs to help keep the others up to date. I didn't know about the macro, will look at that this week. I just tried pocket queries by state and that's a dead end. Another thread in the forums is pushing for allowing more caches in the queries and I can see where that would solve the problem if the States query would download the entire state rather than only a select 1000. I'm going to experiment with the states over a week long test though. If it pulls a different 1000 each time it might still be useful. The problem of power trails should have been nipped in the bud a long time ago.

 

OK, just one last try, then I give up...

 

Use the API, you get a quota of 10000. In GSAK go to "get geocaches", on the dialog window go to "page2", select "state", select the state you want and if you use "light" you get 10000 caches. If you only want traditionals in order to be able to filter them and put them in your ignore list select cachetypes on page one.

 

It's no use to keep beating the dead "PT should be nipped.... " you have the tools to solve this but have to make the choice to just live with it or learn to use the tools. It's as simple as that. Insisting on keeping to use PQs(only) will not do you any good.

[+Mudfrog]

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?

Let's put it this way,,, If i bring up a geocaching map and see a string of caches along a road, then there's about a 99% chance that it's a power trail. Sure we can come up with scenarios and examples for why a string of caches doesn't qualify but really, it's going to be obvious the majority of the time.

 

In your example, why would it matter if there are multiple owners. It it's the same type cache placed over and over .10 miles apart, the intent of the trail to score big find count in minimal time,, it's a power trail.

[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.

Fair suggestions, but of course, the first is extremely labor intensive, and the second relies on 3rd party software that only runs on PCs. A website solution is what the OP and many others are asking for, and that does not seem unreasonable to me. Instead, we continually get what many of us consider "fluff" changes instead of real changes that can positively affect the way we geocache.

 

I realize that you're not a programmer or any other part of the Groundspeak crew, and are only helpfully offering what suggestions you can, but I hope that the powers that be don't take the approach that the problem is solved because we have ignore lists and GSAK.

[knowschad]

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."

I hear you, and I wouldn't want to be that guy, either. But let's not lose sight of the fact that an ugly baby is something that is not under the control of the parents. Ugly caches are.

 

I think that most power trail hiders are deliberately placing a power trail, and are doing it because they want to attract power cachers. I really don't think that it would be difficult at all to get them to use an attribute. I think they'd relish it. Ditto with geo-art cache series.

[+niraD]

I think that most power trail hiders are deliberately placing a power trail, and are doing it because they want to attract power cachers. I really don't think that it would be difficult at all to get them to use an attribute. I think they'd relish it. Ditto with geo-art cache series.

+1

 

The owners are already (mis)using other attributes (e.g., the Scuba Required attribute in the Nevada desert) to help identify the caches in their series. If there is an attribute for this type of fungible geocache, then the owners will almost certainly use it instead of (mis)using other attributes.

[Keystone]

I've stated a few times that adding attributes for power trails and geo-art is a result that's more likely to occur than introducing new cache types. I'm fine with that, so long as application of the attributes is entirely voluntary on the part of the cache owner. If niraD is correct -- and I hope he is -- this solution may be successful. The drawbacks include the thousands of power trail and geo-art caches already in existence -- will the owners take the time to edit them? -- and whether cache owners will view their own contributions to a trail full of caches as "power caches."

[+NYPaddleCacher]

I've stated a few times that adding attributes for power trails and geo-art is a result that's more likely to occur than introducing new cache types. I'm fine with that, so long as application of the attributes is entirely voluntary on the part of the cache owner. If niraD is correct -- and I hope he is -- this solution may be successful. The drawbacks include the thousands of power trail and geo-art caches already in existence -- will the owners take the time to edit them? -- and whether cache owners will view their own contributions to a trail full of caches as "power caches."

 

Over in some other thread the notion of "the perfect solution" was discussed and there was pretty much agreement that, at least in the context of that thread, that "you're not going to please everybody". Then someone posted that even though the proposal might not be "the perfect solution", the net benefit should still justify consideration of the proposal.

 

I see the same scenario here. Perhaps adding attributes for power trails and geo-art isn't a perfect solution because there isn't a globally agreed upon definition of a power trail and not all current owners of PTs and geo-art will add the attribute. Even if only 25% of current owners add the attribute and it's only added for some percentage less than 100% of future power trails and geo-art, isn't that still a net improvement that not only benefits those that want to ignore PT and geo-art but also makes it easier for those that do like that sort of caching to discover cache listing for the types they want to find? That's certainly better than nothing at all.

 

[+Jake81499]

Yea I've used the API for over a year before I started just downloading all of them via the pocket queries. API is too limited. I use the Status check to filter out archived caches and get recent logs to help keep the others up to date. I didn't know about the macro, will look at that this week. I just tried pocket queries by state and that's a dead end. Another thread in the forums is pushing for allowing more caches in the queries and I can see where that would solve the problem if the States query would download the entire state rather than only a select 1000. I'm going to experiment with the states over a week long test though. If it pulls a different 1000 each time it might still be useful. The problem of power trails should have been nipped in the bud a long time ago.

 

OK, just one last try, then I give up...

 

Use the API, you get a quota of 10000. In GSAK go to "get geocaches", on the dialog window go to "page2", select "state", select the state you want and if you use "light" you get 10000 caches. If you only want traditionals in order to be able to filter them and put them in your ignore list select cachetypes on page one.

 

It's no use to keep beating the dead "PT should be nipped.... " you have the tools to solve this but have to make the choice to just live with it or learn to use the tools. It's as simple as that. Insisting on keeping to use PQs(only) will not do you any good.

 

And that's exactly what I'm doing. I've done it before. My API is all set up for 16 states. The API limits are another problem when you have 250000 caches + that you are trying to work with. We shouldn't have to place things in the ignore list. My ignore list is already huge. It needs to be in the Pocket Query creation page. Another thing is that you have to go through each and every pocket query to find those who are creating chains every time you are getting ready to download the query. When things are basically running on automatic that's just not possible. Another user gave me some information that I haven't had an opportunity to try. A macro that filters out caches of the same name is what I'm gathering from it.

Edited April 18, 2016 by Jake81499

[+Jake81499]

I've stated a few times that adding attributes for power trails and geo-art is a result that's more likely to occur than introducing new cache types. I'm fine with that, so long as application of the attributes is entirely voluntary on the part of the cache owner. If niraD is correct -- and I hope he is -- this solution may be successful. The drawbacks include the thousands of power trail and geo-art caches already in existence -- will the owners take the time to edit them? -- and whether cache owners will view their own contributions to a trail full of caches as "power caches."

 

Over in some other thread the notion of "the perfect solution" was discussed and there was pretty much agreement that, at least in the context of that thread, that "you're not going to please everybody". Then someone posted that even though the proposal might not be "the perfect solution", the net benefit should still justify consideration of the proposal.

 

I see the same scenario here. Perhaps adding attributes for power trails and geo-art isn't a perfect solution because there isn't a globally agreed upon definition of a power trail and not all current owners of PTs and geo-art will add the attribute. Even if only 25% of current owners add the attribute and it's only added for some percentage less than 100% of future power trails and geo-art, isn't that still a net improvement that not only benefits those that want to ignore PT and geo-art but also makes it easier for those that do like that sort of caching to discover cache listing for the types they want to find? That's certainly better than nothing at all.

 

Perfect. And over time peer pressure and knowledge will prevail.

[+Jake81499]

I tried the macro CacheSeries. It's somewhat helpful but kind of broken I think. It's supposed to bring up google maps I think and it doesn't. I might be doing it wrong but the maps button doesn't even come up and there's nothing in the macro forum about it. I can export the caches it brings up to a Mapsource map and check from there then add them to my ignore list. It's not at all helpful in areas like DIA where there are thousands of chains and regular caches all set up by the same person who uses his name for the cache name. In that case we would have to ignore the username completely which is not first choice.

Edited April 20, 2016 by Jake81499

[+on4bam]

I tried the macro CacheSeries. It's somewhat helpful but kind of broken I think. It's supposed to bring up google maps I think and it doesn't. I might be doing it wrong but the maps button doesn't even come up and there's nothing in the macro forum about it. I can export the caches it brings up to a Mapsource map and check from there then add them to my ignore list. It's not at all helpful in areas like DIA where there are thousands of chains and regular caches all set up by the same person who uses his name for the cache name. In that case we would have to ignore the username completely which is not first choice.

 

Looks like you're always trying the hard way.

 

Run the macro, choose "only set user flags", in your database press F8... all series are now in your filter.

Select menu "geocaching.com" >> add to bookmark list >> ignore list... Done. These caches wil no longer be in your PQs or on your map at gc.

[+Jake81499]

I tried the macro CacheSeries. It's somewhat helpful but kind of broken I think. It's supposed to bring up google maps I think and it doesn't. I might be doing it wrong but the maps button doesn't even come up and there's nothing in the macro forum about it. I can export the caches it brings up to a Mapsource map and check from there then add them to my ignore list. It's not at all helpful in areas like DIA where there are thousands of chains and regular caches all set up by the same person who uses his name for the cache name. In that case we would have to ignore the username completely which is not first choice.

 

Looks like you're always trying the hard way.

 

Run the macro, choose "only set user flags", in your database press F8... all series are now in your filter.

Select menu "geocaching.com" >> add to bookmark list >> ignore list... Done. These caches wil no longer be in your PQs or on your map at gc.

 

Problem with that is 3/4 of the thousands of caches you ignore won't be chain caches. You have to check them.

 

Run it on a GSAK database covering all of Denver, DIA Fort Collins and the smaller towns in that area. MONDO has thousands of caches in the area. The CacheSeries macro will pick up ALL of his caches, series or not, because they all have the same name. Many of them are fun, legitimate caches. Not checking them will cause you to ignore them. There's no way to separate the legitimate caches from the power caches. That's not what we need.

[+Jake81499]

I tried the macro CacheSeries. It's somewhat helpful but kind of broken I think. It's supposed to bring up google maps I think and it doesn't. I might be doing it wrong but the maps button doesn't even come up and there's nothing in the macro forum about it. I can export the caches it brings up to a Mapsource map and check from there then add them to my ignore list. It's not at all helpful in areas like DIA where there are thousands of chains and regular caches all set up by the same person who uses his name for the cache name. In that case we would have to ignore the username completely which is not first choice.

 

Looks like you're always trying the hard way.

 

Run the macro, choose "only set user flags", in your database press F8... all series are now in your filter.

Select menu "geocaching.com" >> add to bookmark list >> ignore list... Done. These caches wil no longer be in your PQs or on your map at gc.

 

Problem with that is 3/4 of the thousands of caches you ignore won't be chain caches. You have to check them.

 

Run it on a GSAK database covering all of Denver, DIA Fort Collins and the smaller towns in that area. MONDO has thousands of caches in the area. The CacheSeries macro will pick up ALL of his caches, series or not, because they all have the same name. Many of them are fun, legitimate caches. Not checking them will cause you to ignore them. There's no way to separate the legitimate caches from the power caches. That's not what we need.

 

I tried this several times in the last couple days. As an example, Highway to H.E.L.L and Highway to Heaven. CacheSeries brings up both in a single database. In that database there are many other Highway series caches and single highway caches that a person might not want to ignore. If you don't check each series the macro comes up with then you will ignore a large number of caches that don't need to be ignored. I guess if a person doesn't care then they can just select all the lists and ignore everything in them. The macro is a good idea but its just a patch on a bald tire.

Edited April 21, 2016 by Jake81499