Jump to content

Pocket Query


ibycus
Followers 1

Recommended Posts

Was reading yet another "Please include archived caches in PQs" thread, when I noticed a suggestion (or comment), that more or less got ignored by everyone there.

I thought it was a good one, and I doubt that the thread is really going anywhere, so I figured putting it in its own thread might do it some good.

 

I'm guessing the GPX file is going to need to be revised some time soon to include cache attribute data. When this is done, would it be possible to include the parameters that were used to generate the pocket query information?

 

Very simple reason for asking this. If this information were available in a GPX file, then programs could inspect local databases for records that match those specs, but aren't in the query, and then purge those records (or flag them somehow).

 

I know Jeremy doesn't like the fact that people maintain offline databases, and this wasn't what pocket queries were for, but the thing is, people do. People will continue to. Wouldn't it be in everyone's best interest if those databases were reasonable well maintained? (Plus it would shut up all the people asking to include archived caches in a pocket query, when there are very, very good reasons for not doing this).

Link to comment

I've solved this by keeping a register of the PQ name, the parameters used, and also on upload into the database marking which PQ the cache was included in, the date the PQ was loaded and the # of chaches included - this helpd monitor when the next PQ is needed (#16 is next for the UK for me) and also jiggle the previous dates to take into account all the archied ones. Would also like the ability for archived caches to appear in PQ's so marking archived records as such in the offline database is not a manual effort based on not being returned in the PQ.

 

Sue

Link to comment

I first requested that the PQs include some information about the request in January of 2003. At the time, it seemed like a pretty obvious thing to do.

 

Since the necessary changes to the PQ creation code would have taken approximately 5 minutes to implement, I can only conclude that TPTB aren't very interested.

 

In other words, I wouldn't hold your breath.

Link to comment

I really don't want archived caches in Pocket Queries. I don't think its a very good idea. Yeah it makes sense from a database maintenance standpoint, but given that there are quite a number of reasons not to put them in a pocket query (use that there search button to read up on them), I can really understand why TPTB have chosen not to (my guess the biggest reason is a liability issue).

 

As far as not having done it yet, and therefore not interested, times change, things get ignored, priorities shift. Personally I don't care overly much, as I'm slowly converting people around here to disabling their caches for a week or so to allow pocket queries to catch up with the database change, and then archive them.

 

As far as other solutions go, anything less than an automatic solution is going to be a too much of a pain in the arse for most people, and they just won't do it (and they'll continue whining that gc.com is at fault).

Link to comment
I really don't want archived caches in Pocket Queries. I don't think its a very good idea.

Huh? The thing I asked for a year and a half ago was to put the name of the PQ in the query. Who said anything about archived caches in this thread?

 

As far as not having done it yet, and therefore not interested, times change, things get ignored, priorities shift.

 

I am sorry, but I must disagree. Refusing to implement something as trivial as including the name of the query in the query results, despite multiple requests, implies (to me) a complete lack of interest in making them more usable.

 

I actually insert the query name into the query myself using a macro that grabs it from the email text accompanying the PQ. But the very fact that I have to do it at all is pretty sad, given how completely trivial the change would be.

Link to comment
Huh? The thing I asked for a year and a half ago was to put the name of the PQ in the query.

I suggested that the NAME of the GPX file should be the same as the name of the query, which I though would be more useful than having it IN the query. I am not apposed to having it in the query, but having it there would make it useful to databases but not to humans. Its along the same lines as having archived caches in PQ's, they would be useful for database, but not very useful for humans.

Link to comment
Huh?  The thing I asked for a year and a half ago was to put the name of the PQ in the query.  Who said anything about archived caches in this thread?

 

Me. See original post. I was just clarifying why I want what I want. To be honest, I didn't read your link. What I want is the query parameters in the pocket query (i.e. origin, search radius, types of caches returned etc), this would allow a third party app to figure out if a given cache *should* be in a query.

 

I am sorry, but I must disagree.  Refusing to implement something as trivial as including the name of the query in the query results, despite multiple requests, implies (to me) a complete lack of interest in making them more usable.

 

Did they refuse, or did they just not do it? There is a big difference. There are dozens of suggestions every day in the forums. If TPTB can't see the value of it at the moment, it may well allow it to fall to the background.

 

To be honest, I don't really see the point of having the PQ name in the query (maybe I'll go take a look at your thread). But then again, to each his or her own.

Link to comment
Did they refuse, or did they just not do it? There is a big difference. There are dozens of suggestions every day in the forums. If TPTB can't see the value of it at the moment, it may well allow it to fall to the background.

TPTB rarely refuse outright to implement a feature; usually, it just gets ignored. This particular feature is noteworthy for a couple of reasons: the mechanism to do it is already built into the GPX standard (so no extension was required) and adding it was completely trivial; as I wrote before, a 5-minute job, max.

 

(BTW, in response to somebody else's comment that it would be nice to have the file name match the PQ name: that is not possible given the architecture of the PQ system. It requires that each PQ have a unique filename. That's why we originally requested the PQ name in the PQ data -- it would be very easy to write a little program that would automatically rename the files for you.)

 

My point is that if TPTB don't even consider such a trivial change as adding the PQ name worth doing, they are much less likely to implement a change where the PQ parameters are included in the PQ. That's all I was trying to say.

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