ClayJar
-
Posts
962 -
Joined
-
Last visited
Posts posted by ClayJar
-
-
quote:
Okay, so the dry dance doesn't seem to be working... maybe I should try doing the rain dance on the off chance that I might actually be slightly out-of-phase with the real world.
Originally posted by LaGeocaching:Weather is looking like rain. Be prepared... ClayJar needs to pick up the pace.
(Maybe I'll just call in on Friday and camp Thursday night, just to get the full effect.)
I guess I'll be sure to bring my swimming gear... don't think it'll be deep enough for Waverunner rides, but perhaps the canoe is in order.
-
So, I think I'm starting to get a cramp in my shin, but so far it looks like the dry dance might just be working... Got to keep going.
-
quote:
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).
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.
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:
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.
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.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.
-
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.]
-
quote:
Don't go there!
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.)
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.)
-
An automated "slashbox" type thing would be a very nice use of web services, but that does not yet exist. You might want to try writing a clear, concise explanation of what you want to do and then writing Jeremy to ask permission. It's worth a shot, at least.
If you were only displaying a box of the latest/nearest few caches with the names, waypoints, ratings, and such (not the coordinates), and the listed caches were linked to their cache pages on Geocaching.com, and you included an "*as of ##TIMESTAMP##" note with the //gpx/time in it, I'd say you have a decent chance of being in the "allowable (with permission) uses of PQ GPX data". Of course, perhaps Jeremy would not give permission (and there are valid reasons), but I'd tend to think that he'd probably give you permission to do that with your GPX.
-
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. (It does get tedious to keep redoing a query... then again, it's not *that* bad, so if I must, I must.)
-
It should be patently obvious what several of the Louisiana cachers are planning for our next event cache: Louisiana Cacher's Kisatchie Cool Weather Campout (GCCF93) by Louisiana Geocachers (1/1)
Apparently, we're going to have a crawfish boil at the campout (on Saturday)... and ***EVERYONE'S*** invited. Come on down/up/over!
-
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.
(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.
) -
It looks really nice how it is, but as long as the concrete hasn't hardened yet, I may as well ask a few questions about it. (Perhaps these are nits, but they still deserve a few moments.)
Okay, I'm dropping the Groundspeak: prefix for brevity of documentation here (so use your imagination). I just have a few questions (or perhaps it's one long question). I'm wondering about the following nodes with maxOccurs="unbounded" (the ones not mentioned make sense to me):
cache/owner: Will a cache really be able to have multiple owners? cache/attributes: Shouldn't there only be one attributes in which all the attribute nodes are collected? cache/short_description: Can a cache have more than one short_description? cache/long_description: Can a cache have more than one long_description? cache/logs: Shouldn't there only be one logs in which all the log nodes are collected? cache/logs/log/finder: Will a log be able to have more than one finder? cache/logs/log/text: Should a log have more than one text block? cache/logs/log/log_wpt: Will we be able to put more than one log_wpt in a log? cache/travelbugs: Shouldn't there only be one travelbugs in which all the travelbug nodes are collected?One more little Columbo-ism... Can the XML exporting you're using handle simpleTypes? In other words, can you define in the XSD things like this:
<xs:simpleType name="logType"> <xs:restriction base="xs:string"> <xs:enumeration value="Found it" /> <xs:enumeration value="Didn't find it" /> <xs:enumeration value="Other" /> <xs:enumeration value="Needs Archived" /> <xs:enumeration value="Unknown" /> <xs:enumeration value="Archive (show)" /> <xs:enumeration value="Archive (no show)" /> </xs:restriction> </xs:simpleType>
For a log type, size type, cache type, size type, rating type, and so on? That would make life a lot more defined for people coming into the field of GPX apps. If it's too difficult, I can keep the hand updated one I've been using as documentation, but if it were in the XSD, it would be clearer. Not a big deal, since I can keep the separate "sample documentation-only XSD" updated by hand, but if it's not too hard to do, it would be nice to have it as a canonical part of the XSD. -
For now you can use GPSBabel to convert your GPX files (from PQs or Watcher) into a format that you can load into other software (and GPSBabel will even upload directly, with the right settings). You can also use EasyGPS to open the GPX files and upload the coordinates to your GPS receiver. (There is work in progress to make a user friendly interface from Watcher directly through GPSBabel to whatever output, but it won't be done too soon.)
-
-
Some people get into caching and blaze a bright streak across the sky, finding every cache near them as soon as it's listed. Many of them tend to burn out when they can't take the strain of keeping up the pace.
Other cachers go through that stage and then settle down into hobby mode. They stay around, not finding caches at the same rate but caching nonetheless. They have moved caching into perspective; they cache for fun, not compulsively.
When I started caching May 29, 2001, I decided that I'd plan to move from compulsive caching into hobbyist caching before I flamed out. I cached every week for an entire year, and then I slowed down. I no longer have that compulsive need to find every new cache near me, but when I'm planning a little vacation or I'm going on a hike, I'll look for caches to do. I've made it well past the burnout zone and become a recreational cacher, and I can continue like this indefinitely.
(It's better once it's a hobby, too, since you can figure out what you really want to hunt and ignore the ones you don't. I rarely do easy caches, but when I want to, they'll be there. The really hard ones are far more my style.
) -
It's not the quantity, it's the paddling.
Assigning a number is not exactly logical, really, since it wouldn't be compatible with the way many of us cache. I don't often say, "Oh, look, a cache near me!" and run out the door. I usually spend a few hours with Watcher going through five states of cache pages to find the few that *really* interest me, and then I sometimes might take a whole weekend to do just one.
For others, perhaps numbers are more applicable.
-
My weekend schedule change takes effect next weekend, which means I get to camp Friday through Sunday! Now I just have to see how early I can get out there Friday. (I doubt J. will be able to make it, but I'll ask her anyway.
) -
Sorry... I was preoccupied with my new '96 Waverunner III to read the forums... Oops. (I tried it out, by the way, and it runs well.)
-
If you are a paying member of Geocaching.com, you get some really nice extra features. One of them is called the "Pocket Query Generator". With it, you can tell Geocaching.com to e-mail you up to five sets of up to 500 caches each on the days you specify. You simply have to set it up to send you "GPX" files and then you can use any of a large number of available programs to do all sorts of cool things.
You can use a program to change GC#### to $$#### based on type or whatever. You can use GPSBabel to convert the GPX file to MapSend or whatever other file format you use on your PC. You can use Watcher (which I write) to do *all sorts* of things (like sorting, viewing, searching, filtering, etc). And those are just the beginning.
(In other words, come ask in the geocaching chat about the various things you can do with Pocket Queries. We can convince anyone, given enough time, and if we can't, I'll add more features to Watcher.
) -
quote:
It's not connected to Geocaching.com primarily because over a year ago a bunch of us basically decided on our own to have a chat, and I tracked down a Java chat client, paid the registration, and set the whole thing up. It was basically a grassroots thing.
Originally posted by Kiwi Cruiser:I wonder why it is not connected to this site? I just went and had a quick look at it ... it seems O.K.
Quite a while back Jeremy said that he'd get it all set up on Geocaching.com if I didn't want it, but since I'm perfectly happy hosting it and since I'm "in charge" of the official chats each Monday night at 8:30 Central US (01:30 UTC, if I recall correctly), I might as well keep the few bytes on my server. (And as has been noted, some people have issues with Geocaching.com for whatever reason, and this way they can be involved; I try to keep people from disparaging *any* site... there's just no need to be rude.)
Of course, if there was a "Geocaching chat" link somewhere people can notice it, that would be fine, but if there's not, we have enough geochatters to reply to the topic whenever it comes up.
-
Well, thanks to unanimous consent among GPX developers, the logjam was declared cleared and Watcher 0.1.31 can finally be released. New features in Watcher 0.1.31 include (but are in no way limited to) the following:
- Smart merging: Always use the most recent cache details.
- Coordinate limits: You can set N/S/E/W boundaries to filter on.
- Special filters: Filter by hiders, states, or even countries.
- Advanced sorting: You can sort by whatever in whatever order.
- WYSIWYG saving: The order you see on the list is the order it saves.
-
Whenever my compass gets really cold it develops a bubble, but it only takes a pocket to bring it back to proper bubble-free operation. I'd assume that the liquid in it contracts more rapidly than the plastic casing, and so the pressure inside decreases until the point where the pressure inside is less than the vapor pressure of the liquid at that temperature.
Can someone tell me what the liquid usually is in a $10 map compass? I'd like to look it up in some tables to see what the internal pressure must be to have a vapor bubble at that temperature. Then I could compare that to atmospheric pressure to determine the delta, which would finally tell me how much those bits of plastic can take (at least). Then I can stop being afraid I'll break my wonderful little compass.
-
Since the reason I won't release the next update to Watcher is that I don't want to potentially splinter the Groundspeak namespace, we have an alternative that could be considered.
If and only if we the developers of Groundspeak-extension-comprehending GPX utilities can reach a de facto agreement on what the node will be and what it means, then we would not need Jeremy to add the node before moving forward.
The proposed one-line change to the Groundspeak cache XSD is to add the following (more details in the previous thread):
<xs:element name="exported" msdata:Prefix="Groundspeak" type="xs:dateTime" minOccurs="0" />
This would mean that if "//gpx/wpt/Groundspeak:cache[@id=$ID]/Groundspeak:exported" exists, it is the canonical exported timestamp of that waypoint's cache details. If that node does not exist, all waypoints in a GPX are assumed to be exported with the timestamp specified in "//gpx/time".
When merging Groundspeak-extended GPX files, a program should use these fields in this order to determine which is the most recent cache waypoint. Also, as a general but non-deterministic rule, when transforming GPX contents into other formats, whether displayed on screen or saved in PalmDoc, HTML, or another arbitrary format, whenever possible and logical the exported timestamp should be included in order to preclude the inadvertant use of stale cache pages.
So, the question is now posed to all of us. In order for me to count it as a de facto agreement, we need an affirmative or non-negative reply by the developers of Watcher, GPX Spinner, gpx2html, GPX View (for PocketPC 2002), and GPX to PalmDoc. (And if I forgot someone, apologies and you too.)
Do you, Groundspeak/GPX developers, approve of the proposed node under as proposed in the "*Very* important GPX request." thread and noted here?
Watcher votes yes.
-
Okay, I've added lots of new things to Watcher, and version 0.1.31 is sitting on my PC waiting anxiously to be released (anthropomorphism, perhaps, but hey). There remains only one thing that needs to be done before I can release it.
I need an answer from Jeremy (or anyone who counts) to the *Very* important GPX request. thread.
Since tomorrow morning will be the four week anniversary of the thread, I figured I'd celebrate the event by having a little poll. Note that this is a thoroughly non-scientific poll and is only meant to get at least a few people to take notice of the fact that I am fast getting weary of waiting so long for a simple answer. (Note that by "an answer" I mean an answer in boolean (sense 2). A "yes or no" answer. True or false. A determinate answer.)
So, the question is simply this:
When do you want the next Watcher to be released?
-
I'm going to be going through five or so states this weekend, so I won't be able to release anything after tomorrow evening... Is there any chance that we can get an answer about "exported" before I leave so I can release 0.1.31, or is there a chance there might be an answer by Monday?
I really don't mean to sound perturbed or anything, but I'm getting really tired of sitting on this and not releasing. If I have to go back in and remove all the work on the advanced merging code, I will. If I don't, that's even better. If I need to work on a new namespace, I will. Frankly, I don't give a plug nickel *HOW* I get 0.1.31 released. I just want to get this thing out! I don't even need you to do ***ANYTHING*** other than to just say "yes" or "no" so I know whether to release as-is (even if it is ahead of the XSD update itself) or to pursue alternate methods of handling the situation.
All I want is one tiny answer.
-
...partially hydra...hydrogen...ated... soybean oil ...mono--sodium... glue...glute...glutenate...
Shemwells on Today morning show.
in General geocaching topics
Posted
DeerChaser & Poni,
As a GPX application developer, I almost never have any IE window maximized, since I have many windows open at a time on my 1600x1200 screen. It would help me if you would use a graphic that is not as wide. Would it be possible for you to change it, if not for anyone else's convenience, then for mine?
Thank you.
ClayJar
Watcher Developer
Official Weekly Chat Moderator
[Watcher Downloads] - [Official Geocaching Chat]