Jump to content

REQUEST: Active and inactive Pocket Queries


GeoROCKS!

Recommended Posts

I have my typical 25-mile-radius caches-near-home Pocket Query "bubble" that I get via email every night, and I have several others for areas to which I frequently travel.

 

My problem is that I often create a query that I'd like to keep because I really like the results it gives me, but I end up having to replace it with another one because of the five-query limit.

 

What about adding functionality to create unlimited queries, yet having only five of them being "active", the others with an "inactive" status?

 

Once that's done: [slightly off my own topic icon_wink.gif], but what about also adding functionality to create a query with a differently shaped bubble, specifying in the query TWO coordinates that define the upper-left and lower-right points of a rectangle within the boundaries of which caches could be found? That would solve the difficulty in obtaining a relevant query for caches near long, straight stretches of highway!!

 

[This message was edited by GeoROCKS! on March 06, 2003 at 03:01 AM.]

Link to comment

You might want to try using Watcher on your Pocket Queries. You can have any sorting or filtering abilities to a GPX that you would ever want, including caches within a coordinate rectangle (or portion of a rectangle!). It might also solve or help you with your 5+ Pocket Query dilemma.

 

To get Watcher, go to http://www.clayjar.com/gc/temp/, or ask about it in the #Geocache chat room.

 

If carrots are so good for the eyes, how come I see so many dead rabbits on the highway?

Link to comment

Incidentally, Jeremy said that the Pocket Query generator will indeed have a rectangular search added. I wouldn't look for it right away, but you don't need to re-request it since it's on his TODO list already. icon_smile.gif

 

(And at least one person actually e-mailed me that they used Watcher's coordinate limit filters to filter the caches along their route, so that's already there. icon_wink.gif)

 

[Watcher Downloads] - [Official Geocaching Chat]

Link to comment

I'm familiar with Watcher (thanks to ClayJar's efforts!), but I don't think it provides a workaround to the 5-query limit, does it? Sure, it'll help pare down the results, but that's not my problem -- I don't have much of an issue with receiving more caches than needed along a route or in a given area. If I do, Watcher will be my tool of choice!

 

Instead, I'm looking for a solution that will let me keep the queries I normally use (i.e. my main Caches Near My House query, and oft-used "bubbles" such ones in Alameda, San Joaquin, San Francisco, and Calaveras counties. But if I plan a less-typical road trip to, say, Lake Tahoe, then I might want to download caches in located in the Walnut Creek, Vacaville, Sacramento, Placerville, and Tahoe bubbles -- requiring that I overwrite all queries (the fastest method) or at least one (wait until the data arrives, then repeat four times)...

 

Of course, I COULD get around it by creating a couple new user accounts and subscribing each as a member (or asking Equinox to delete HIS queries icon_biggrin.gif instead of mine!), but that's certainly less than practical. Now, I MIGHT consider paying an extra fee (or subscribing to some sort of power-user membership) in order to receive more queries...

Link to comment

Along the same lines as GeoROCKS! is discussing, here is my take on what would be good for me. Quite often, I don't know where I'm going to go until the night before so the chance of getting a pocket query is just about nil. What I'd like is the ability to fire off a limited number of one time queries, which would return in a reasonable amount of time (1 to 2 hours). By limited number, I'm saying like 2 to 4 per week. That doesn't seem like it would be too much of a burden on the server.

 

I do like GeoROCKS! suggestion about the saving of a higher (or unlimited) number of pocket queries, but only having 5 active at any given time. Seems very easily implemented, and very useful.

 

--Marky

"All of us get lost in the darkness, dreamers learn to steer with a backlit GPSr"

Link to comment

quote:
Originally posted by jeb and co:

It would also help to keep track of pocket query request data if a dummy cache was also reported withe the info used to create the query (query name,lat, lon, radius etc.)


Don't go there!

 

I know you were just brainstorming, but that was a very, very bad direction to storm in. If you want the PQ options in the PQ GPX, then by all means, suggest that, but they do NOT belong in there as a dummy waypoint. Fortunately, the GPX XSD has placeholders for any extensions you'd like to add to the file. The Groundspeak cache extensions are under each //gpx/wpt, but you could just as easily extend //gpx with Groundspeak Pocket Query attributes.

 

So, while there are certainly valid reasons to possibly include the PQ options in the generated GPXes, under NO circumstances should those options be kludged into a dummy waypoint. (And just in case anyone is confused, no, I'm not in the least bit upset. I'm just *exceedingly* terrified that someone could actually implement such a kludge, and I do *not* want to have to deal with the Microsofting of PQ GPX.)

 

[Watcher Downloads] - [Official Geocaching Chat]

Link to comment

quote:
Originally posted by ClayJar:

So, while there are certainly valid reasons to possibly include the PQ options in the generated GPXes, .... I'm just *exceedingly* terrified that someone could actually implement such a kludge, and I do *not* want to have to deal with the Microsofting of PQ GPX.)


I can feel the terror several states away.

 

But it would be nice to have the PQ options available done correctly of course. This would be especially useful for searches done as radius from a center. I really would like to add a distance from center index to my GPX to Plucker remailer.

Link to comment

quote:
Originally posted by ClayJar:

Don't go there!__

 

I know you were just brainstorming, but that was a very, _very_ bad direction to storm in. If you want the PQ options in the PQ GPX, then by all means, suggest that, but they do __NOT__ belong in there as a dummy waypoint. Fortunately, the GPX XSD has placeholders for any extensions you'd like to add to the file. The Groundspeak cache extensions are under each //gpx/wpt, but you could just as easily extend //gpx with Groundspeak Pocket Query attributes.

 

So, while there are certainly valid reasons to possibly include the PQ options in the generated GPXes, __under NO circumstances__ should those options be kludged into a dummy waypoint. (And just in case anyone is confused, no, I'm not in the least bit upset. I'm just *exceedingly* terrified that someone could actually implement such a kludge, and I do *not* want to have to deal with the Microsofting of PQ GPX.)

 


 

I still think it would be an ecellent idea to include a dummy waypoint giving the query details wether it was kludged (what a delightful expression) or skilfully programmed by Elias or whoever. For those who find the prospect less than desireable this could be an option.

Link to comment

quote:
Originally posted by jeb and co:

I still think it would be an ecellent idea to include a dummy waypoint giving the query details wether it was kludged (what a delightful expression) or skilfully programmed by Elias or whoever. For those who find the prospect less than desireable this could be an option.


 

The use of a dummy waypoint is a kludge regardless of how skilfully it is programmed. icon_wink.gif The data is valuable, it just doesn't belong in a waypoint. There are places that it does belong as described by ClayJar above. icon_smile.gif

 

--Marky

"All of us get lost in the darkness, dreamers learn to steer with a backlit GPSr"

Link to comment

quote:
Originally posted by Marky:

 

The use of a dummy waypoint is a kludge regardless of how skilfully it is programmed. icon_wink.gif The data is valuable, it just doesn't belong in a waypoint. There are places that it does belong as described by ClayJar above. icon_smile.gif

 

--Marky


I have not yet seen any reason to describe a dummy waypoint as a kludge. It would give the user of the information instant access to the details they submitted to retrieve the query as well as the date and name of the query. At the moment the last two are only available from the mobipocket output. The loc file and gpx files are given a number and so the link to the original query is lost. As I suggested above, if you don't want to have the kludge then don't tick the box to get it.

Link to comment

quote:
Originally posted by jeb and co:

 

I have not yet seen any reason to describe a dummy waypoint as a kludge.


 

If the information being described isn't a physical location then it's not a waypoint. Calling anything else a waypoint is a kludge. If, for example, a mapping program displayed the phone number of a local hotel as a waypoint (after all, it already know how to display waypoints, why learn new tricks) that would be a kludge.

 

Clayjar is totally right; it's good information to have and there are better places for it.

Link to comment

quote:
Originally posted by jeb and co:

I have not yet seen any reason to describe a dummy waypoint as a kludge.


I have tried to describe why it is, but now I will get into the details, since you have obviously not become familiar enough with the GPX XSD to understand them yourself.

quote:
It would give the user of the information instant access to the details they submitted to retrieve the query as well as the date and name of the query.

And putting those details in the GPX in the location designed for them (as opposed to in a kludged dummy waypoint) would in no way make them less usable.

quote:
At the moment the last two are only available from the mobipocket output. The loc file and gpx files are given a number and so the link to the original query is lost. As I suggested above, if you don't want to have the kludge then don't tick the box to get it.

No. Making a kludge optional in no way makes it right. Whether it's optional or not, all GPX application developers would have to know about the kludge and support it, or they would have errors introduced in their applications by the fact that someone kludged the system. Now, for your benefit, I will attempt to explain two lines of the GPX XSD and their context so that you can stop arguing for something that you know not nearly enough about.

 

The content of GPX files is defined in an XSD (XML Schema Definition) located at http://www.topografix.com/GPX/1/0/gpx.xsd.

 

Line 52:

 

This line is a placeholder for any extended content that a GPX implementation wants or needs to add to the waypoint definition in the base GPX XSD. In the case of Groundspeak Pocket Query GPX files, the information added here comes from the Groundspeak GPX waypoint extensions GPX located at http://www.Groundspeak.com/cache/1/0/cache.xsd.

 

If you wanted to kludge the waypoint data into a waypoint (or its Groundspeak extensions), you'd have to stuff that square peg into this round hole. What would go in the //gpx/wpt/desc? What does //gpx/wpt/time mean for the kludge? The information DOES NOT BELONG in a dummy waypoint.

 

Line 171:

 

This line is a placeholder for any extended content that a GPX implementation wants to add to the main (non-waypoint, non-route, non-track) definition in the base GPX XSD. In the case of the current implementation of Groundspeak Pocket Queries, there is nothing here, but since this is information specific to the file and not specific to any particular waypoint, route, or track in the file, it is where you would put things like the parameters used to create the file.

 

There would simply need to be an addition Groundspeak PQ XSD to define the data to be included here (just as the Groundspeak Cache XSD defines the data to be included in the extended waypoint information). The Groundspeak PQ XSD could specify things like a //gpx/center node that has lat, lon, and radius child nodes. It could specify that the user for whom the PQ was made should be encapsulated in a //gpx/user node. It could, frankly, say anything that it needs to say.

 

Hopefully you can now see how adding a dummy waypoint is a very, very bad and ill-formed idea, especially since there is a place to put the information. If you want to learn more about how XML, XSD, GPX, and PQs work, I'd be more than happy to help you get up to speed (just come to the chat and we'll go over some of it real time, since it can indeed be daunting at first). Just remember, not everything in the GPX specification is used in Pocket Queries, so you can certainly not look at a Pocket Query GPX and make statements about GPX. You have to look at the XSDs to get the information to understand the discussion.

 

XML (and XSDs, etc) was specifically designed so that application developers don't have to worry about people kludging things. XML is very strict with some things so that developers don't have to enter the morass of infinite kludgery, and those of us who have dealt with massive kludge-fests of file formats will fight to the last man to prevent the creation of even more.

 

[Watcher Downloads] - [Official Geocaching Chat]

 

[This message was edited by ClayJar on March 07, 2003 at 01:16 PM.]

Link to comment

So, a dummy waypoint in GPX is not an answer to having information on the query that generated the data. It seems from comments above that there is a place to put the information but Groundspeak have yet to come across with the alterations required and this is causing developers some anguish. To cause them some more anguish and possibly delay the implementation they require, two alternative places that the 'query' could be reported suggest themselves:

 

1) In the email that accompanies the data file. This does have the name of the query and the date it was generated so the other information could accompanyit.

 

2) In the first page of the mobipocket book. Again this already contains some of the information and it should be easy to add the rest.

 

I hope that these two suggestions won't also be described as kludges as there are, as far as I am aware, no email or mobipocket protocols that they upset.

 

Back to GPX. The only reason I started to ask for queries in this format was because of the glowing reports of packages that used this data such as gpx2html and Clayjars watcher, both of which I have used and found in their different ways to be excellent, but until there is further development I will revert to Mobypoceket for cache information and loc files and easygps to downlaod waypoints to my gps and to Autoroute.

Link to comment

quote:
Originally posted by jeb and co:

So, a dummy waypoint in GPX is not an answer to having information on the query that generated the data. It seems from comments above that there is a place to put the information but Groundspeak have yet to come across with the alterations required and this is causing developers some anguish. To cause them some more anguish and possibly delay the implementation they require, two alternative places that the 'query' could be reported suggest themselves:

 

1) In the email that accompanies the data file. This does have the name of the query and the date it was generated so the other information could accompany it.

 

2) In the first page of the mobipocket book. Again this already contains some of the information and it should be easy to add the rest.


Both of those places would be nice additional places to include the PQ details, but the details should most certainly be included in the PQ GPX, and they should be included in the PQ GPX where they belong. The reason they are not there yet is because prior to this portion of this thread, a big deal has never been made over it. It is readily apparent to all involved that having the PQ details would be very good, and so we have all joined in requesting it (and requesting it using the knowledge of the GPX specification that you do not currently posess; a fact that can be easily remedied if you would consent to joining us so we can help you get up to speed on it, since you sound like you would be a valuable member once you understand GPX XML's XSDs).

 

Also, the fact that Geocaching.com has not implemented something that, although it is a good idea, none of the developers really had noticed enough to considerably request in no way causes the developers anguish. The thing that causes developers anguish is when people who could be very helpful do not take the little time necessary to understand the background of the situation. It is impossible to have an implementation discussion without knowing how the implementation pieces fit together. Your three suggestions are evidence that you are a very creative-minded individual and would likely be exceedingly helpful in coming up with useful things, but first you need to know what everyone is talking about. I have given you an open-armed offer of assistance to help you quickly get up to speed so you can understand the basics that underlie all the implementation discussions. I urge you to accept the invitation.I hope that these two suggestions won't also be described as kludges as there are, as far as I am aware, no email or mobipocket protocols that they upset.Don't act dumb -- you are not dumb, and if you want to learn enough about XML, XSD, GPX, et al to understand how it all works, my offer of assistance stands. Ignorance is most certainly not bliss, especially when it would likely not take more than a quick backgrounder to explain the basics enough for you to understand.

quote:
Back to GPX. The only reason I started to ask for queries in this format was because of the glowing reports of packages that used this data such as gpx2html and Clayjars watcher, both of which I have used and found in their different ways to be excellent, but until there is further development I will revert to Mobypoceket for cache information and loc files and easygps to downlaod waypoints to my gps and to Autoroute.
I myself continue to use Mobipocket eBooks on my PDA. It's just a matter of convenience for me; since I've been spending an inordinate amount of time working on Watcher, I haven't managed to get familiar with GPX to PalmDoc or gpx2html with Plucker. However, since later versions of EasyGPS work with GPX files, and since GPSBabel can convert the GPX files to almost every imaginable format [ed. note: I can imagine some it doesn't do, but I know a lot], why in the wide, wide world would you request LOC files with your PQs instead of GPX files? I mean, hey, both EasyGPS and GPSBabel will give you LOC files from GPX files if you really want LOC, but only time travel or black magic will give you a GPX with full data when given a LOC as input.

 

Anyway, let me once again offer to help you get up to speed on the GPX XML XSD. I seriously doubt it will take very long at all to understand it, and once you do, you'll be able to have useful discussion about implementation details with the various GPX developers, and trust me, we could use all the knowledgeable discussion you can provide.

 

[Watcher Downloads] - [Official Geocaching Chat]

Link to comment

quote:
Originally posted by ClayJar:

It would be exceedingly nice if we could save PQ settings for more than five queries and then simply check "Activate" on the five we want.


 

I just purchased my membership today, and have been playing around with Pocket Queries. They're great, but I'm in the same boat as ClayJar and others here. I was going to make this very same suggestion, but found this old thread...

 

There are several places that I travel to a few times a year (for work, visit family, etc.) and it would be exceeding handy to store those searches with a "disabled" setting so they don't count against the 5-search limit.

 

Since the places I visit are separated by thousands of miles, it's not practical to post-process the results using software like Watcher.

Link to comment

I just tried this and it appears to work and would give you unlimited 'stored' Pocket Queries:

 

Save the PQ you wish to store as an HTML file using your browser.

Edit the HTML file as follows:

--Replace the line:

<FORM ACTION="./default.asp" METHOD="POST">

with:

<FORM ACTION="http://www.geocaching.com/pocket/default.asp" METHOD="POST">

--Remove the ID# (sample is 99999) from the following line:

<INPUT type=hidden value=99999 name=ID>

--Replace the line:

<INPUT type="submit" value="Edit this search" name=editSearch>

with:

<INPUT type="submit" value="Create this search" name=createSearch>

 

Now save this again. Any time you want to recreate this PQ you just have to click on your saved HTML file and hit create search icon_smile.gif

Link to comment

quote:
Originally posted by YeOleImposter (formerly yragnosluap):

Now save this again. Any time you want to recreate this PQ you just have to click on your saved HTML file and hit create search icon_smile.gif


That seems like a good idea. I have not tried this yet because I did not want to mess with the queries I currently have saved and waiting to go. But I did have one question. For this to work does the "Remember me" checkbox need to be checked at some point prior to running the saved file?
Link to comment

I open the file after I am already in the PQ 'system'. In other words instead of hitting 'create a new PQ' I open my saved PQ. So I am already logged in, etc. AFter opening the saved PQ HTML file - it shows the saved PQ and I can hit refresh.

Does this make sense? This step just saves me from entering all the data since it is saved in the HTML file.

Link to comment
quote:
Originally posted by YeOleImposter (formerly yragnosluap)icon_biggrin.gifoes this make sense? This step just saves me from entering all the data since it is saved in the HTML file.
Oh OK I see what you are doing. Makes perfect sense. I was not sure how you dealt with the log on part of it. I agree I am always forgetting to select something or putting the wrong dates in or whatever. That should save time and frustration.
Link to comment

I also like the idea of 'query on demand'.

 

Not sure how that would be programmed but I find myself in that 'oh crap... I can go caching' situation and not have a query ready to go fairly often. Less often now that I don't travel as much for business, but still.

 

It'd be sweet if you could have like others have said. Higher limit of queries configured, but only be able to run 5 a day whether by schedule or "insta-query"

 

--------

trippy1976 - Team KKF2A

Saving geocaches - one golf ball at a time.

Flat_MiGeo_A88.gif

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