Can Someone Explain This About The Pq Generator?

[+Cheminer Will]

Gently, please! Also correct any misunderstandings I may have about the logic and the system.

 

It seems that TPTB have put a lot of effort into trying to make sure the PQ's run smoothly for the highest number of people. Part of this has been the coding that runs PQ's based on how recently the same PQ has previously been run. This is why a new PQ runs almost right away. And why a weekly scheduled PQ keeps getting generated later in the day until it is finally skipped

 

More and more of us run the same PQ's every week or even twice a week so that we keep our logs up to date in our offline databases. This is because if more than 5 logs have been entered for a cache since the last time it was included in our PQ, we miss those logs. I understand that some people are completely uninterested in user logs on a cache. But some of use really like to have them all to read when we go after a particularly interesting, difficult, or destination cache.

 

I THINK TPTB limit the PQ's to 5 logs to reduce the size of the generated PQ files? Although how much space do logs really take up in the PQ? I am also thinking that the advantage of only including 5 logs is starting to be offset by the number of people running frequent PQ's to get around this limitation. If I run 25 PQ's in a six month period to try and capture all the logs, how is this better for the system than running only 2 PQ's during that same time frame, but including 20 user logs instead of 5 in each PQ? The default # of logs could still be 5, but we could choose to include a greater number if wanted.

 

I know that if I could choose to include a larger number of logs in my PQ's, this would pretty much eliminate the need to run the PQ's every week. It would also mean that if I have a scheduled trip, I could just run the PQ's the week before I go. For example, we are doing a 3 week camping trip soon. I ran the first PQ's for this trip 6 months ago and many times since. this is so that when I use GSAK on the trip, I will have as many of the logs as possible. If I could choose to include say, 20 logs in my PQ's, then I would have only had to run each of the PQ's for this trip once or twice.

 

So I guess this is really a long winded way of asking why we can't have the choice of how many logs to include in our PQ's? How would this muck up the PQ system? Yes more logs are included in a PQ IF you choose to include them, but many fewer PQ's would be run.

Edited July 19, 2006 by Cheminer Will

[robertlipe]

This has long been a requested feature - dating back to the first few weeks of PQs, in fact.. I think a LOT of PQs are being ordered up and aggregated offline exactly to get around the five log limit. All it takes is one carload of cachers to destroy the usefulness of logs.

 

June 3 Cacher A Found with Power Train

June 3 Cacher B Found with Power Train

June 3 Cacher C Found with Power Train

June 3 Cacher D Found with Power Train

June 3 Found using Herbert's coords below that are a mere 800 feet from the cache. Thanx, Herbert!

June 1 Herbert: Used fone a friend with placer. Cache page is wrong. Corrected coords...

 

Lots of seekers really do want more than five logs. I found 25 to be a reasonable compromise when I was worried about such things. That's old enough that "herbert's" coords would finally make it to the real page in almost all cases and it captures the interesting part of the history.

 

Sometimes, though, you want to study an area and don't care about logs at all or you don't even care about the 'long term' history. I proposed pulldown of options for "0, 5, 10, and 25" logs, but that never went anywhere. Would most people choose the "supersize" option for everything? Would there be a net reduction because people could order up fewer PQs to capture log history? I really don't know.

[+The Leprechauns]

I think that, human nature being as it is, many people would select the maximum number of available logs "just because they can," and that many people would use the freed-up pocket queries to build a more expansive offline database. The net result could be an even greater drain of data down the pipe.

 

I'm just speculating, of course.

[+budd-rdc]

I've looked at GPX files with a text editor, and know that there's noticeable difference in file sizes between 5 and 20 logs.

 

For GC1B4D:

 

5 logs: 5389 bytes

20 logs: 15240 bytes

 

Many of us receive the files zipped:

 

5 logs: 2070 bytes zipped

20 logs: 4689 bytes zipped

 

For people who didn't know, I just hinted at a workaround, but the waypoints will have to be downloaded individually.

 

I would love to see an option to see more logs per GPX in PQs, but it's not critical.

[+tozainamboku]

Here's another idea. Have an option to return all the logs from the last seven days instead of the last five logs. For most caches this will return fewer than five logs, while for a few very popular caches and for events it may return many more than 5. Still for most PQs the total number of logs will be less. Of course you may miss logs that were back dated.

[+Jamie Z]

I think that, human nature being as it is, many people would select the maximum number of available logs "just because they can," and that many people would use the freed-up pocket queries to build a more expansive offline database. The net result could be an even greater drain of data down the pipe.

I like the idea, but I agree completely with Lep. This feature will be abused.

 

Here's another idea. Have an option to return all the logs from the last seven days instead of the last five logs.

This is a fantastic idea.

 

Jamie

[+Hynr]

Here's another idea. Have an option to return all the logs from the last seven days instead of the last five logs.

This is the feature I would like to see. I'm pretty sure that nearly all my gpx files would be smaller than they are now. Coupled with "updated during last 7 days" this would be much more efficient.

[+StarBrand]

Out this way the last 7 day option would likely return no logs on many of the caches. Need to be able to select last 5 or last 7 days. Try to combine the 2 and "abuse" (as stated above) will occur and make the PQs longer instead of average shorter.

[+FamilyDNA]

Here's another idea. Have an option to return all the logs from the last seven days instead of the last five logs. For most caches this will return fewer than five logs, while for a few very popular caches and for events it may return many more than 5. Still for most PQs the total number of logs will be less. Of course you may miss logs that were back dated.

 

I would not prefer that option, as there would likely be fewer logs in my download. I don't compile an offline data base. I run a pq for what I want when I need it. If I'm taking a trip but can only get the last week's worth of logs, I might not have any past logs for a cache I'm seeking.

 

If it's an option people can choose, I'd say it sounds good, but the default 5 logs should also stay available.

[+Cheminer Will]

This has long been a requested feature - dating back to the first few weeks of PQs, in fact.. I think a LOT of PQs are being ordered up and aggregated offline exactly to get around the five log limit. All it takes is one carload of cachers to destroy the usefulness of logs.

 

June 3 Cacher A Found with Power Train

June 3 Cacher B Found with Power Train

June 3 Cacher C Found with Power Train

June 3 Cacher D Found with Power Train

June 3 Found using Herbert's coords below that are a mere 800 feet from the cache. Thanx, Herbert!

June 1 Herbert: Used fone a friend with placer. Cache page is wrong. Corrected coords...

 

Lots of seekers really do want more than five logs. I found 25 to be a reasonable compromise when I was worried about such things. That's old enough that "herbert's" coords would finally make it to the real page in almost all cases and it captures the interesting part of the history.

 

Sometimes, though, you want to study an area and don't care about logs at all or you don't even care about the 'long term' history. I proposed pulldown of options for "0, 5, 10, and 25" logs, but that never went anywhere. Would most people choose the "supersize" option for everything? Would there be a net reduction because people could order up fewer PQs to capture log history? I really don't know.

 

Thanks, Robert! As usual, your answers, and or suggestions are right to the point. I'm glad to know that this has been proposed in the past so at least it has been considered. I was just thinking about ways to lessen the load of PQ's by not having to run as many, as often. But as others have pointed out, anything gained by my wish and your suggestions could be negated if most people just chose the biggest number of logs available. I think it possible that most would choose 25 logs, but having that option should greatly reduce the total number of PQ's being run to keep offline db's up to date. I wonder what percentage of all PQ's are ones that are scheduled and run every week, or more often?

 

I think a lot more people are now keeping offline db's up to date with weekly or more frequently scheduled PQ's, at least for their local area.

[robertlipe]

Freakishly, I hunted a cache tonight that, without access to > 5 logs, was essentially unfindable. I don't aggregate logs so all I had was five. Using the web browser in my cell fone, I was able to get the correct cache page info. His projection was a mere hundred degrees off...

 

(Yes, the cacher should totally fix the cache page. I'll work that tomorrow.)

 

I don't know that 25 or even 20 is the right number, but I've always thought 5 was too few.

 

I don't think the human nature/greed thing is as cut-and-dry as Lep suggests, though it's certainly a factor to consider.

 

I know there are times when I would choose "zero" as the number of logs to receive. It's possible that I'm the only one, but surely there are others that sometimes review PQ's for travel and are just trying to get circles that touch, study cache type and density, splash things on a map, and so on. I don't always _want_ logs.

 

I also know that some cachers DO want more than five logs. The "found in last seven days" doesn't work because there can be more than five. Those cachers are getting that aggregating logs locally and in order to get the data, they're running PQs several times a week or even daily. As pointed above, the individual GPX downloads do include more. If you're concerned about the number of bytes being served, neither of those are good behaviours to condition, either as they have the opposite effect.

 

Folks are going to get this either via aggregation or by the site giving them something closer to what they want.

[CoyoteRed]

Folks are going to get this either via aggregation or by the site giving them something closer to what they want.

 

This is very true.

 

We aggregate simply because we've run into the exact same thing you've mentioned earlier, but we didn't have the option a web-enabled cellphone. Some of our PQs run twice a week and we are forced to get the full load of active caches.

 

I've suggested before the all logs in the past 7 days. This would reduce the number of PQs to only run once a week.

 

I've also demonstrated the issue with not sending down the archived caches. On a typical week only about a quarter of the caches are actually being updated, a maximum of around a third. That translates into about two thirds to three quarters of the PQ is wasted space. I understand the desire to not send down archived caches, but I had a solution to that as well in that only those caches archived in the last seven days are sent down.

 

Now there is an option of only sending down any cache that has been updated in the last days, but these do not include archived caches. The archived caches are essentially lumped with the caches that haven't changed. You don't know if the cache has been archived or simply hasn't been visited. Big problem when an irate land owner forces the immediate removal and archival of a cache. "In Last 7 Days Aggregators" could be in big trouble!

 

Combine all of these proposals into one and basically you get a "Give me all activity in the last 7 days." These PQs would only have to run once a week and would reduce the size of the files dramatically.

 

However, the respond I always get back from those who it would do the most good simply leads me back to doing it the hard way--full and complete lists. My attitude is why should I care if they don't?

 

Personally, given the choice of aggregating logs and downloading the last 25 logs, I'd prefer the aggregating. That way I'm not at the mercy of this site's reliability as I figure 1 week old stale data is better than the however-many-week-old stale data of the last PQ from that area--or none at all.

[+welch]

I don't care much either way about the 5 log limit, what I would personally like is the ability to trade a weeks worth of PQ for say one that has 5,000 waypoints, or maybe all caches within 100 miles. Something that would allow me to capture the whole state (or for those in super dense areas at least a few miles). To do that now you need to run multiple PQs to get the data, and then several more to keep it up to date. My thinking is if its easier to just do a whole new 'state' PQ, many people trying to get bits and pieces everyday would stop.

Yes I could see people ordering a PQ with 5,000 instead of 500 because they can, but if even if they do, thats still only half of the waypoints they could do, so it'd still be a benefit, right??

[CoyoteRed]

My thinking is if its easier to just do a whole new 'state' PQ, many people trying to get bits and pieces everyday would stop.

 

This would work. One query, many downloads.

 

As long as each cache has the complete log history offline software can determine if you've found it or not. (I actually make my own GPX file with the caches I which to show as found, but haven't logged online, and have a log inserted. Works pretty good.)

 

To save bandwidth, you could have a complete set and one that includes only those changed in the past 7 days.