Jump to content

All Finds Pq

Stunod

By Stunod
in Website

Followers 6

Recommended Posts

fizzymagic

+fizzymagic

Posted
Posted
Perhaps you didn't read closely. The PQ is returning archived logs...logs we have deleted. These should not be showing up.

Why not? The archived logs in question are marked as archived in the PQ, I believe. Just because your software doesn't use the archived status of the logs in deciding whether to include them or not doesn't mean the PQ is broken.

 

OTOH, if the logs are not marked as archived, then there is a problem with the PQ. But my guess is that, since archived logs never show up in regular PQs, programs like GSAK don't even look at the status of logs.

Link to comment
Corp Of Discovery

+Corp Of Discovery

Posted
Posted

OK. I just ran mine again (probably able to do it so soon due to the change in how you run it). The problem is now out of 1337 finds only 31 have found logs. Some of the caches (with and without found logs) have deleted notes from personal TB's/coins. The 31 is just about the same number of deleted found logs that showed up the first time I ran this PQ. The PQ number is 353368 if it helps.

Link to comment
budd-rdc

+budd-rdc

Posted
Posted
Fizzy brought up a good point so I checked. Logs do *not* have any attributes to specify if they are archived or not.

Arrrgh. Second time I've been wrong in three days. I must be losing my touch...

Or you forgot to turn on your WAAS. :anibad:

 

I ran mine twice, once using [set Option] version and again using [schedule Now] version.

 

Personally, I don't mind seeing archived logs and notes to a cache I already found. Since I like to move around TBs by revisiting old caches, this is an easy way to find out. If this gets fixed, though, I won't miss it.

Link to comment
Monkeybrad

+Monkeybrad

Posted
Posted

All I want to say is THANK YOU to the guys and/or gals manning the controls. The ability to work with a database of all my found caches is awesome. I am having a blast making the windows machines cough up lungs trying to plot routes and the such. Seriously, I had asked for this feature several times (pretty much anytime there was an opportunity), so I want to thank you for making it available. Once a week is plenty, I would have been happy with once a month. So thanks again.

Link to comment
blackjack65

+blackjack65

Posted
Posted

Hi, and thanks to the Powers That Be

for this new feature.

 

However, I have encountered an issue that has not been pointed out in this thread:

 

That PQ does not contain any indications of TBs currently in the caches.

 

This may seem logical, since it can only be updated weekly,

but it overwrites the PQs already in GSAK, and if a TB appears in a cache

I have already found, I can thus miss it.

 

Since TBS do not answer to the same find and swap rules as regular swag,

since their goal is to travel as quickly as possible,

I see this as a problem since I have to override the My Find PQ

with a regular PQ to see closeby TBS,

hence rendering the My Find PQ less usefull.

 

I suppose it was done this way to make the file lighter,

since it is not limited to 500 caches.

Link to comment
ClydeE

+ClydeE

Posted
Posted (edited)
Sounds more like a GSAK problem than a problem with the PQ.

I would have thought the PQ would just reflect the current information for the cache when it is produced - why should this information be excluded?

 

I mean, this is not GSAK specific. If you open up that PQ in any software it is going to always tell you there are no travel bugs in all these caches, which may not (and probably isn't) the case. As with any PQ, wouldn't it make sense to include the travel bug information that is available when this PQ is done?

Edited by ClydeE
Link to comment
Hynr

+Hynr

Posted
Posted
Sounds more like a GSAK problem than a problem with the PQ.

It is not a GSAK problem. It is a lack of data integrity because absence of TB information for a particular cache in a PQ indicates that there is no TB in that cache at the time the PQ is generated. How is any third-party software supposed to update TB information for a particular cache, if this cannot be assumed? I rather suspect that this is an oversight because the amount of data involved is relatively small.

Link to comment
fizzymagic

+fizzymagic

Posted
Posted

I'm sorry. This is a GSAK problem, not a problem with the query.

 

People are treating PQs as if they are databases. They're not. They are specific queries into a database. The results of a query do not necessarily contain all of the information in the database.

 

The purpose of the "all finds" PQ is to allow geocachers a record of all caches they have found. Period. It's not intended to be used to supplement a database of all the caches in the area or anything else. The query does not contain the most recent logs for the caches, or the current TBs in the caches, or the last date the cache was found, or any other extraneous information. And it shouldn't. This query is not like other queries. That's why it has its own special interface.

 

GSAK treats this query like any other query. That is a problem with GSAK, since this query is not intended to be treated like any other query.

 

The Groundspeak GPX extensions allow TB information to be included with cache information, but they do not require it. Third-party software should not make assumptions about the contents of PQs that are not stated anywhere.

 

I am perfectly willing to let TPTB know when they do something I don't like. But I am really quite disgusted at the behavior I have seen since they gave us this special PQ. Rather than figuring out how to make the most of the information we now have available, people have concentrated on complaining about how it doesn't work exactly the way they want it to.

 

It's pretty sad. I just hope the same thing doesn't happen when we get our long-awaited queries along a route.

Link to comment
fizzymagic

+fizzymagic

Posted
Posted
I mean, this is not GSAK specific. If you open up that PQ in any software it is going to always tell you there are no travel bugs in all these caches, which may not (and probably isn't) the case.

Really? Could you show me in the Groundspeak GPX specification where it says "if there are TBs in the cache, they must be included in the GPX file?" I looked all over and I just couldn't find it.

 

If you are claiming that this is a data integrity issue, then, by your logic, we must insist that all logs for every cache be included. After all, if those logs aren't in the GPX file then they don't exist, right?

Link to comment
ClydeE

+ClydeE

Posted
Posted (edited)
I mean, this is not GSAK specific. If you open up that PQ in any software it is going to always tell you there are no travel bugs in all these caches, which may not (and probably isn't) the case.

Really? Could you show me in the Groundspeak GPX specification where it says "if there are TBs in the cache, they must be included in the GPX file?" I looked all over and I just couldn't find it.

 

That's not what I said. I am saying that any 3rd part software that displays this data will not have this information and it is not a GSAK specific issue. As the code must already be there when building other PQs I would of thought it would be logical to include this data. By including as much data as possible (similar to a normal PQ) you are more likely to be compatible with software that is already using the existing PQs

 

This may not be a Groundspeak priority, and I personally never said this was wrong. I am just saying that from a 3rd party software perspective it would be nice if this information is included. Consider it a request if you will.

 

Don't get me wrong. I like others am very grateful for the new all finds PQ and I am happy to accommodate changes if necessary. A heads up telling us what might be missing from these PQs might have been helpful though.

 

Edit: I understand your argument about the data not having to be included in the GPX file (and I agree absolutely), but if it is included might we not expect the data to reflect the current value in the Groundspeak database? The current reason this is tripping up GSAK in the post by Blackjack65 is that the all founds PQ includes the following element <Groundspeak:travelbugs />

 

This element implies we have travel bug information but it is empty (that is, we are saying "there are no travel bugs in this cache", rather than "we are not supplying any information about travel bugs in this cache". Shouldn't this element be removed from the GPX file if Groundspeak are not providing this information?

Edited by ClydeE
Link to comment
ClydeE

+ClydeE

Posted
Posted
I'm sorry. This is a GSAK problem, not a problem with the query.

 

People are treating PQs as if they are databases. They're not. They are specific queries into a database. The results of a query do not necessarily contain all of the information in the database.

 

The purpose of the "all finds" PQ is to allow geocachers a record of all caches they have found. Period. It's not intended to be used to supplement a database of all the caches in the area or anything else. The query does not contain the most recent logs for the caches, or the current TBs in the caches, or the last date the cache was found, or any other extraneous information. And it shouldn't. This query is not like other queries. That's why it has its own special interface.

 

 

But that is the issue I have with your argument - if they really didn't provide the information GSAK would be happy. The issue for me is that for travel bugs, they are in fact provding this information, and the information is not an accurate reflection of the data.

 

The inclusion of <Groundspeak:travelbugs /> is providing us with this information. Like the other logs etc that you say aren't there, if this information is not meant to be passed on, then why include it?

Link to comment
fizzymagic

+fizzymagic

Posted
Posted
The inclusion of <Groundspeak:travelbugs /> is providing us with this information. Like the other logs etc that you say aren't there, if this information is not meant to be passed on, then why include it?

You make a very good point; I agree that it would be best if the <Groundspeak:travelbugs> section were left out.

 

However, having it in despite having incomplete information is consistent with the <Groundspeak:logs> section, which certainly does not contain all the log information for the cache.

 

I still think that the best solution is to treat the All Finds PQ as a special case that is only intended as a report of the user's finds.

 

Using queries to try to populate a local database is a chancy proposition at best; I think it causes more problems than it solves. Obviously, you differ. But since I am pretty sure that TPTB aren't too happy about people using PQs to try to mirror the geocaching.com database, I wouldn't expect them to go out of their way to make it easier. :D

Link to comment
Pengy&Tigger

+Pengy&Tigger

Posted
Posted

Thanks for the new feature.

 

I have a problem in that one of the caches I have found isn't being included. The cache is GCCB76. It's a locationless that we logged twice on July 26 2004. the logs are still there and have never been deleted. The cache still shows up in our stats but is not in the all finds PQ.

 

Even if I download a GPX file directly from the cache page while logged in, our logs are still not included.

 

Tigger

Link to comment
Team DEMP

+Team DEMP

Posted
Posted
But since I am pretty sure that TPTB aren't too happy about people using PQs to try to mirror the geocaching.com database, I wouldn't expect them to go out of their way to make it easier.  :ninja:

I guess that's the difference between some folks view of good customer service.

 

There are some folks that would go out of their way to help and some that turn away. Something could be made simpler for all with what is possibly a single line of code or commenting out an existing line. As a developer, yes, I know it's THAT EASY, at least in this case.

 

It's unfortunate that the answer in these forums so often is "deal with it".

Link to comment
Corp Of Discovery

+Corp Of Discovery

Posted
Posted

I already have a gpx with all my finds. What I would use this PQ for is to update the status of those finds, in other words to see what ones are active/disabled/archived at present. The only logs I care to see would be my unarchived logs. Even tho I don't do TB's so much, having current info on them could be quite useful to many others. The last time I ran it it was basically useless as archived logs were still showing up in it, while no unarchived logs were there. It's not a problem with GSAK, it's the PQ itself. If all people wanted was a list, that is available thru your online account. I think many, if not most, would want a little more.

Link to comment
beejay&esskay

+beejay&esskay

Posted
Posted

The "all finds" PQ will be a wonderful tool when the issues are worked out.

 

The last time I ran this PQ (11/3, 3:43PM) it had all my found caches and my find log included (and my deleted find log not included). The only problem was the line <Groundspeak:travelbugs /> asserting that there were no travel bugs in caches that had travel bugs.

 

I don't think any of the startup issues are intentional attempts to cause difficulties. I think they are normal issues with any new feature.

 

While I think it is better to have the actual list of travel bugs, just as in any other PQ, it would be acceptable to not say anything about travel bugs. (But NOT to say none exist if they do.)

 

I'm hopeful this will be worked out by the next time I can run this PQ.

 

:ninja:

Link to comment
robertlipe

robertlipe

Posted
Posted
The inclusion of <Groundspeak:travelbugs /> is providing us with this information. Like the other logs etc that you say aren't there, if this information is not meant to be passed on, then why include it?

You make a very good point; I agree that it would be best if the <Groundspeak:travelbugs> section were left out.

I agree that seems most consistent with intended use and general "XML-ness". It seems an easy solution. (Well, unless the PQ generator doesn't really know that this is an AFPQ and it just taking the data from a modified SELECT WHERE.)

 

However, having it in despite having incomplete information is consistent with the <Groundspeak:logs> section, which certainly does not contain all the log information for the cache.

I think there is difference. TB data is highly transient. Logs are kind of a windowed (last 5 + yours) view into an eternal march of the logs. The absence of a log doesn't mean the log went away; it means it's fallen off the window. To date, the TB data has meant "here is a list of TB's in this cache". The absence of a TB used to mean the TB is not there; now it means it's either not there or it came from this slightly different PQ.

I still think that the best solution is to treat the All Finds PQ as a special case that is only intended as a report of the user's finds.

Unfortunately for the reader, there is no positive indication that any given PQ _is_ an AFPQ to make that distinction. It could make a guess based on the global <name> but that's not fail safe and it's kind of tacky. The writer could know if it's an AFPQ or not. If there was a <Groundspeak:af_finds>True< /> or something to pass to the reader, that would be a viable solution. Given the reluctance to change that namespace, I don't see that as a likely change. Besides, if you were going to change the PQ writer to add this tag, it would be even easier to just plain not include TB data for this case.

 

Using queries to try to populate a local database is a chancy proposition at best; I think it causes more problems than it solves.  Obviously, you differ.  But since I am pretty sure that TPTB aren't too happy about people using PQs to try to mirror the geocaching.com database, I wouldn't expect them to go out of their way to make it easier.  :D

 

This point comes up frequently when there is a problem reported in the source data by the GSAK user base and I don't get it. If you're a travel bug hound, the reality is that the all finds PQ and the normal PQs interact badly but in an admittedly subtle way. It has nothing to do with mirroring the database.

Link to comment
fizzymagic

+fizzymagic

Posted
Posted
This point comes up frequently when there is a problem reported in the source data by the GSAK user base and I don't get it. If you're a travel bug hound, the reality is that the all finds PQ and the normal PQs interact badly but in an admittedly subtle way. It has nothing to do with mirroring the database.

I understand the difficulties, and you are correct.

 

I should take back my strong language. It came from my concern that if we complain too much about the data we get from TPTB, they might just decide to not give us as much. Since I am especially anxious to get some kind of PQ along a route going, I am worried that if something relatively easy to understand and use like the All Finds PQ causes a lot of complaints, they might decide that queries along routes are too much trouble. But on further reflection I think that's an unrealistic fear, and I shouldn't worry so much.

 

Here's the connection between these queries and future queries along a route:

 

It seems to me that the problem here is that we are attempting to infer properties of a query from the data results of the query. This same problem has come up in previous contexts; for example, trying to figure out if a cache is missing from a PQ because it is archived or because it is outside the radius of the PQ.

 

Trying to "reverse engineer" the query from the results is, in general, an intractable problem. We've been "lucky" so far because PQs have not been very flexible; they only have a few user-adjustable parameters. But with the addition of the All Finds PQ, and the inclusion of attributes into PQs, it has become more complicated. And this same problem is going to appear in different guises as PQs become more flexible.

 

That's why it would be so valuable to have some of the query parameters included in the query results.

 

For now, it is pretty easy to detect All Finds queries by their <name> fields, but, as you point out, that's not a very robust solution.

Link to comment
fizzymagic

+fizzymagic

Posted
Posted

By the way:

 

In about a week, once the format of the All Finds PQ settles down, I will be releasing an application that will populate an Excel spreadsheet with the results in such a way that you can calculate lots of fun statistics. I'm using Excel because it will allow you to process your finds interactively in a bunch of different ways to calculate quantities like your total caching distance, caching totals by cache type or difficulty or month, etc.

 

Stay tuned.

Link to comment
fizzymagic

+fizzymagic

Posted
Posted
It shoud automagically turn off after the last time its run. Did you press the button at all to generate it? ( I know your post doesn't make it sound like you did, but I got to ask. )

I just got one last night, and I did nothing to generate it. I think it's been exactly a week since I triggered my first one.

Link to comment
budd-rdc

+budd-rdc

Posted
Posted

I did press the button which said [schedule Now] before it ran on November 1st. The button was untouched since, but I noticed that it has changed to [Add to queue] with the letters grayed out, and this was before it ran this morning.

 

If I didn't hit the button, someone or something did. <_<

Link to comment
Monkeybrad

+Monkeybrad

Posted
Posted

I just want the folks at Groundspeak to know that there are lots and lots of us out here that are thrilled with the allfins query. At an event Saturday night, most of the gc.com related conversation was about the new all finds query and geocoins (of course). I did not hear anyone who was worried about whether or not you could see tb's or any of theother issues being discussed here. Everyone was very happy to have the info available.

 

I don't mean to make light of the issues here. I am sure that everyone is working to try to make this feature even better and more useful, but I wanted you to know that there is a great "silent majority" who are really pleased with this new feature. So thanks again for making this information available.

Link to comment
Stunod

+Stunod

Posted
  • Author
Posted
I got my All Finds yesterday and all the problems I reported have been successfully fixed.  Thanks!!!!

I don't see that you complained about TBs missing ... so ...

 

Do you know if TB information is included now?...or, if not, has the

 

<Groundspeak:travelbugs>

 

been removed?

Looking at the PQ results, I still see the following (single) tag on each record:

 

<Groundspeak:travelbugs />

 

This is identical to the first PQ I got on 10/31.

Link to comment
PDOP's

+PDOP's

Posted
Posted
I got my All Finds yesterday and all the problems I reported have been successfully fixed.  Thanks!!!!

 

Mine came today and my find count is correct. Thanks for the fix

 

It shoud automagically turn off after the last time its run.  Did you press the button at all to generate it?  ( I know your post doesn't make it sound like you did, but I got to ask. )

I just got one last night, and I did nothing to generate it. I think it's been exactly a week since I triggered my first one.

 

Same thing here.

Link to comment
PDOP's

+PDOP's

Posted
Posted (edited)
Mine didn't show up yesterday.. but of course I didn't hit the button :D

Ah yes but had you set it up with the radio buttons on the first version of the PQ page? My unrequested (but appreciated :D ) PQ showed up a week later on the same day I had selected originally by "radio button" and had then reset to "Off".

Edited by PDOP's
Link to comment
Stunod

+Stunod

Posted
  • Author
Posted
Mine didn't show up yesterday.. but of course I didn't hit the button :D

My "Add To Queue" button is still grayed out, which seems (to me) to indicate that it will keep coming every week in perpetuity. I have not touched it since the first time I hit the button.

Mine stayed grey-out until EXACTLY 7 days after I ran it the first time...to the minute.

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