DECLINED - LOC Bookmark file Missing Archived Caches

[+2Dee2Dee]

The LOC Bookmark file created after selecting all or some of the caches in a Bookmark list is missing all archived caches even though you can clearly check them for inclusion. The user interface does not need any change. We just need the programming switch removed that filters or restrict archived caches from this LOC file.

 

The goal is to load the file into GSAK for manipulation. So LOC or GPX can work.

 

I can use the GoogleEarth KML file which is also available through the Bookmark and by the way it DOES contain all selected files. I can then convert it into a GPX file, but, that is unnecessary extra problematic work and more importantly it doesn't contain the unique GC ID code field but only an individual hyperlink back to Groundspeak cache page along with other important fields.

 

When using Bookmark lists for confirming such things as challenge or compilation cache verification we need to obtain all the selected caches in a specific Bookmark list, not necessarily one of your own. Those lists are displayed on a cache page if set as Public.

 

With a 5 PQ limit a cache owner doesn't have enough unused PQs to use them to obtain what should be available through the Bookmark list LOC file.

 

Please address this important bug so that what we see, (Bookmark List), we get when we download a file.

 

Thanks for the consideration,

Dennis

[+Hitech MD]

I just PQ'd a bookmark list with archived caches in it and put the gpx file in GSAK and all the caches (including archived caches) where loaded in the database. A LOC file returned all the caches including archived ones but a LOC file doesn't have status information. Now a PQ that queries as opposed to a fixed list, won't include archived caches.

 

HiTech MD

[+The A-Team]

A LOC file returned all the caches including archived ones

I just tried it myself, and the LOC did not contain the archived caches. If I choose just a single archived cache, the LOC file I get has the following contents:

<?xml version="1.0" encoding="UTF-8"?>

<loc version="1.0" src="Groundspeak">

</loc>

Is the list you used a public one that we can try? Maybe there's something special about it.

[+2Dee2Dee]

I just PQ'd a bookmark list with archived caches in it and put the gpx file in GSAK and all the caches (including archived caches) where loaded in the database. A LOC file returned all the caches including archived ones but a LOC file doesn't have status information. Now a PQ that queries as opposed to a fixed list, won't include archived caches.

 

HiTech MD

 

Specifically we are talking only about results from a Bookmark List. Not how things may work on other pages.

The Bookmark LOC file DOES NOT return all selected caches.

Please do a test yourself on a Bookmark list that contains one active and one archived cache.

Yes the PQ file contains both.

You will note that the LOC file created from the same bookmark DOES NOT contain the archived cache.

This appears to be an unintended bug in the LOC file creation for the Bookmark list. You judge that all caches SHOULD be in the LOC file if they have been selected and are in the PQ file.

Thanks for your input but please run a personal test of the issue.

Dennis

[+2Dee2Dee]

A LOC file returned all the caches including archived ones

I just tried it myself, and the LOC did not contain the archived caches. If I choose just a single archived cache, the LOC file I get has the following contents:

<?xml version="1.0" encoding="UTF-8"?>

<loc version="1.0" src="Groundspeak">

</loc>

Is the list you used a public one that we can try? Maybe there's something special about it.

 

You achieved the same results. Great!!! The Bookmark LOC file DID NOT contain the selected archived caches.

Can we have someone check the code and remove the code lines that is filtering out the archived caches in the Bookmark LOC file.

I get the same result with any Bookmark list but yes the ones I am referring to can be seen on the cache page http://coord.info/GC3AMJJ

Thanks,

Dennis

[+paleolith]

I suspect that this is intentional. As has been discussed ad nauseum, GS is very reluctant to make it easier to obtain coordinates for archived caches, since many times they were archived due to land owner/manager request. Unpaid members can get LOC files whereas GPX is only for paid members, so GS can at least say the information is restricted to members about whom they have more contact information.

 

Perhaps it would be more productive to look for other ways to achieve your goal, since I think you're tilting at windmills asking for GS to make it easier to get info on archived caches. For example, would it be possible to compile a list of all the eligible caches into a GSAK database? How many caches are eligible? Once that's done, you could add caches as necessary one at a time, generally because someone posted a list containing archived caches. Over time, your list would include most of the archived caches. You can "get recent logs" using GSAK direct access with no limits on total number (just throttled), so you can update the logs for your DB as often as you need to. A GSAK macro could then run and determine eligibility. In fact, it could even tell you who is eligible and probably doesn't even know it.

 

Edward

[+2Dee2Dee]

I suspect that this is intentional. As has been discussed ad nauseum, GS is very reluctant to make it easier to obtain coordinates for archived caches, since many times they were archived due to land owner/manager request. Unpaid members can get LOC files whereas GPX is only for paid members, so GS can at least say the information is restricted to members about whom they have more contact information.

 

Perhaps it would be more productive to look for other ways to achieve your goal, since I think you're tilting at windmills asking for GS to make it easier to get info on archived caches. For example, would it be possible to compile a list of all the eligible caches into a GSAK database? How many caches are eligible? Once that's done, you could add caches as necessary one at a time, generally because someone posted a list containing archived caches. Over time, your list would include most of the archived caches. You can "get recent logs" using GSAK direct access with no limits on total number (just throttled), so you can update the logs for your DB as often as you need to. A GSAK macro could then run and determine eligibility. In fact, it could even tell you who is eligible and probably doesn't even know it.

 

Edward

 

Thanks for reply but it appears that you have missed the point. I am premium member. I fully understand GSAK and how to harvest the Found/Unfound caches I need for most anything.

In this narrow case I am referring to the ability to specifically obtain the coordinates for ALL the caches that are marked in specific bookmark lists. This action is specifically needed for compilation/challenge verifications. Test the problem for yourself.

 

The narrow [bUG] issue is that you can obtain all marked cache coordinates including archived/unarchived caches from a bookmark list using a PQ. But there are never enough empty PQs in my case to use for such verification tasks as a CO.

 

Instead, on the same bookmark page where a PQ is available with ALL bookmarked caches I just need the LOC button on the same page using the same marked set to return the SAME archived/unarchived set of caches as the PQ or KML sets do. Nothing more nothing less. No database infringement issues are violated since the data is available as PQ or KML. Nothing is being restricted in this case EXCEPT the LOC file itself has uniquely been filtered with code to eliminate the archived caches whereas the PQ has not.

Dennis

[Moun10Bike]

I will agree that it is inconsistent to restrict download of archived caches in LOC while allowing them in KML, but rather than "fix" the LOC file (which eliminates them by design), the answer would be to fix the KML download to also exclude them. paleolith is correct in explaining that we do not want to make it easier to obtain the coordinates for archived caches. Unfortunately, things have grown up organically on the site over time leading to such inconsistencies.

[+2Dee2Dee]

I will agree that it is inconsistent to restrict download of archived caches in LOC while allowing them in KML, but rather than "fix" the LOC file (which eliminates them by design), the answer would be to fix the KML download to also exclude them. paleolith is correct in explaining that we do not want to make it easier to obtain the coordinates for archived caches. Unfortunately, things have grown up organically on the site over time leading to such inconsistencies.

 

Thanks for the reply and courtesy,

I would argue that the PQ obtained from a bookmark page does in fact contain both archived/unarchived if selected, but for purposes of verifying I never have enough personal PQs to use for this kind of verification issue for all the caches I own or to prove such caches that I find. We just need to periodically obtain such lists without using a personal PQ.

 

For compilation/puzzle/challenge caches we frequently need to use the same caches we get through the bookmark page PQ but without using a PQ. Many compilation/puzzle/challenge caches request the use of a public named bookmark as partial verification. The LOC file creation button in the bookmark page could satisfy this well enough in some cases. (I understand the fields limitations in the LOC file.) For this narrow issue though we just need the LOC created from a bookmark list to return the same selected bookmark list caches including archived caches if selected with coordinates for verification tasks.

This is NOT asking for any more caches than is supplied in the PQ from a bookmark list. We just need the GCID, Name, and Coordinates in order to visualize on a map or manipulate through GSAK route queries for verification.

 

The KML does in fact include them but then converting that file into a useful GCID, Name, Coordinate file is difficult due to the field configurations, naming conventions, and hyperlinks it contains. I have unsatisfactorily tried many KML-GPX conversion methods. The names, ID, and coordinates don't come across correctly from the KML.

 

If we could easily harvest the GCID, Name, and Coordinates from the KML file that could be a cumbersom workaround.

 

Thanks again for investigating this important and frustrating problem to resolve methods of compilation/puzzle/challenge verification. Any help in resolving this problem would be appreciated by many of us.

 

Dennis

[+Lil Devil]

I'm failing to understand why you're unwilling to run a PQ, which has everything you want.

 

For the one Challenge Cache that I own, which has someone completing it about once every couple of months, I don't have any problem running a PQ. Even if you have more active Challenge Caches, what are we talking about? One or two PQs a week?

[jholly]

I will agree that it is inconsistent to restrict download of archived caches in LOC while allowing them in KML, but rather than "fix" the LOC file (which eliminates them by design), the answer would be to fix the KML download to also exclude them. paleolith is correct in explaining that we do not want to make it easier to obtain the coordinates for archived caches. Unfortunately, things have grown up organically on the site over time leading to such inconsistencies.

 

Thanks for the reply and courtesy,

I would argue that the PQ obtained from a bookmark page does in fact contain both archived/unarchived if selected, but for purposes of verifying I never have enough personal PQs to use for this kind of verification issue for all the caches I own or to prove such caches that I find. We just need to periodically obtain such lists without using a personal PQ.

 

For compilation/puzzle/challenge caches we frequently need to use the same caches we get through the bookmark page PQ but without using a PQ. Many compilation/puzzle/challenge caches request the use of a public named bookmark as partial verification. The LOC file creation button in the bookmark page could satisfy this well enough in some cases. (I understand the fields limitations in the LOC file.) For this narrow issue though we just need the LOC created from a bookmark list to return the same selected bookmark list caches including archived caches if selected with coordinates for verification tasks.

This is NOT asking for any more caches than is supplied in the PQ from a bookmark list. We just need the GCID, Name, and Coordinates in order to visualize on a map or manipulate through GSAK route queries for verification.

 

The KML does in fact include them but then converting that file into a useful GCID, Name, Coordinate file is difficult due to the field configurations, naming conventions, and hyperlinks it contains. I have unsatisfactorily tried many KML-GPX conversion methods. The names, ID, and coordinates don't come across correctly from the KML.

 

If we could easily harvest the GCID, Name, and Coordinates from the KML file that could be a cumbersom workaround.

 

Thanks again for investigating this important and frustrating problem to resolve methods of compilation/puzzle/challenge verification. Any help in resolving this problem would be appreciated by many of us.

 

Dennis

 

I was thinking the answer is obvious to the casual observer, go get another account, pony up the $30 bucks to make it premium, and you now have another 35 PQ's to burn a week on what ever you desire.

[+Lil Devil]

After doing some testing, I'm going to describe 2Dee2Dee's complaint in slightly different terms. I see where he maintains the bug is, but I think the bug is elsewhere.

 

We'll start with some history. Bear with me here.

 

If you play with the "Nearest Cache List" such as this one in my town, you will notice that this list excludes archived caches.

 

That same page can also show a person's hides or finds. Here is my finds. If you click the double-right-arrow >> to go to the last page, you'll see that archived caches are shown, but there is no checkbox to download the archived ones in a LOC file.

 

Later, when bookmark lists were added to the site, they adapted that same page as one method to display the bookmark list.

 

Interestingly, there are check boxes next to the archived caches, but as 2Dee2Dee said, they are not included in the LOC file. He calls that a bug.

 

I think the bug is that the checkboxes are next to the archived caches at all.

[+2Dee2Dee]

After doing some testing, I'm going to describe 2Dee2Dee's complaint in slightly different terms. I see where he maintains the bug is, but I think the bug is elsewhere.

 

Interestingly, there are check boxes next to the archived caches, but as 2Dee2Dee said, they are not included in the LOC file. He calls that a bug.

 

I think the bug is that the checkboxes are next to the archived caches at all.

 

The useful checkboxes allow the bookmark list owner to batch delete or batch export as a PQ as needed.

We need to retain the check boxes so that the bookmark list owner and those they share their bookmark list with can select ALL caches if they choose and those selections including archived/unarchived caches would at least be available through a PQ as it now operates.

My finds list of course includes archived/unarchived caches I have found. This is not much different.

 

Lets not make this narrow bookmark list issue worse rather than better. Bookmark lists have many uses and sharing ALL the caches within a list is only one of many uses. We need to continue the ability to select caches from a bookmark list for whatever reason is necessary at the time.

 

Dennis

[+baloo&bd]

After doing some testing, I'm going to describe 2Dee2Dee's complaint in slightly different terms. I see where he maintains the bug is, but I think the bug is elsewhere.

 

Interestingly, there are check boxes next to the archived caches, but as 2Dee2Dee said, they are not included in the LOC file. He calls that a bug.

 

I think the bug is that the checkboxes are next to the archived caches at all.

 

The useful checkboxes allow the bookmark list owner to batch delete or batch export as a PQ as needed.

We need to retain the check boxes so that the bookmark list owner and those they share their bookmark list with can select ALL caches if they choose and those selections including archived/unarchived caches would at least be available through a PQ as it now operates.

My finds list of course includes archived/unarchived caches I have found. This is not much different.

 

Lets not make this narrow bookmark list issue worse rather than better. Bookmark lists have many uses and sharing ALL the caches within a list is only one of many uses. We need to continue the ability to select caches from a bookmark list for whatever reason is necessary at the time.

 

Dennis

 

I think everyone is talking past each other. To put in a very simple statement what has already been said;

 

_GS does not want you to have the ability to easily download or obtain information on archived caches. Period._

 

Caches are archived for many reasons, some of which are legal or safety, and GS it appears would much rather they be treated as if they never exist. When you understand the reasoning, it makes very good sense.

 

GS has allowed them to be viewed for whatever reason. As such, for a challenge that may allow archived caches to be used, you would have to go to the caches individually.

 

However, since enough people have pointed out the inconsistencies, I am sure it is on their punch list to fix the bugs such as the check boxes appearing next to archived caches, removing them from the KML, etc.

 

If it is the cache of yours I suspect it is, I am surprised it got approved with requirement #5, which in part is where your question may originate from.

Edited February 4, 2012 by baloo&bd