Jump to content


+Charter Members
  • Posts

  • Joined

  • Last visited

Posts posted by ClayJar

  1. quote:
    Originally posted by The Leprechauns:

    OK, I finally broke down and installed Watcher, but I can't get it to open. Reading this thread, I next went and updated to Internet Explorer 6. Still no dice. When I click on the Watcher icon, I get a message that says "A required .DLL file, MSVBVM60.DLL, was not found." What do I do next?

    That would be because you don't have the runtime files. (Um, where have you been the last few years? icon_wink.gif) It just so happens that I have the runtime in the very same directory already, but apparently nobody pointed you to it, so...


    VB6 runtime setup.


    Just install that and you'll have made it to the late '90s at last. icon_wink.gif (Only have to do this once, of course.)

  2. quote:
    Originally posted by The Diver:

    GCAE5 - Geocache by Pezman and Jitters


    FYI...In the GPX, the Groundspeak:name comes out like this:


    That cache has no name in the database. Geocaching.com uses "Geocache" as the default name when no name exists. (Any GPX-using program may decide to do the same, but that's up to the programmer.)
  3. After a busy morning, I can say that Watcher 0.1.9 came and went and 0.1.10 is now out. (Yep, another two-fer. You should check more often. icon_razz.gif)


    Included are brand new cache type icons (thanks to brdad for hand-redrawing the small ones for me). Also included is the ability to filter the list by cache type. Have fun. icon_biggrin.gif


    Get it at the usual place.

  4. quote:
    Originally posted by sbell111:

    A 'rectangle' search would also be handy when planning a trip.

    Now that you mention it, Team Ninefruits was just asking me about whether he could use the pocket queries to search for caches along his route. If he could have drawn several long rectangles, that would have done nicely, indeed.
  5. After a busy morning, I can say that Watcher 0.1.7 came and went and 0.1.8 is now out.


    Included are some HTML/non-HTML fixes, mentioning it if you need a better IE, closing completely (oops), being able to open a new GPX from inside Watcher, and remembering the window positions (unless you pass "--forget-window-positions" on the command line).


    Get it at the usual place.

  6. Okay, so I was chatting away while slinging code on Watcher, and something came up in the discussion that seemed like a possibly useful idea. Since none of us could markwell the topic, I figured I'd post it here.


    The Problem:


    The most efficient way to get a full state's worth of caches is to do a pocket query by state; however, when the state grows to more than 500 caches, you can no longer use one query to fetch all the caches. It *is* possible to segment by type, but once the state has grown past 500 traditional caches, even that becomes impossible. Using multiple overlapping radial queries is possible, but it is far from efficient in both its use of pocket queries and also its use of the database (since the queries *must* overlap and therefore *will* include duplicates, plus the distances must be calculated for each cache in each query).


    One Possible Solution:


    The cachers using the pocket queries are going to find a way to get all the caches they're interested in. At present, that means they are putting extra load on both the database and themselves. This situation could be solved by creating the facility to combine pocket queries. If you want to return up to 1000 caches, you would spend not *one* pocket query point but *two* pocket query points on it, and it would return up to 1000 caches.


    The problem with allowing cachers to spend more than one pocket query point on a query is simple. Resources. Since I am not in any way privy to how the system is setup, I cannot say whether returning 1000 caches for one pocket query would tax the system more than returning three pocket queries totalling somewhere around 1200-1500 caches in order to get the same full set. Elias, Jeremy, et al, I leave that question for you to reply to. (If fewer but larger queries would indeed tax the database more, please do tell us so that we can use it to markwell this should it ever come up again. icon_smile.gif)


    An Alternate Solution


    Choosing overlapping circles is both hard and inefficient. "Rectangles", on the other hand, are quite easy to create (just pick two points on a map) and efficient to filter (A < coord < :D. [Note: They're not perfect rectangles, due to the fact earth is round, but they're good enough.]


    If you could add an "and is inside this rectangle" to the pocket queries, it would be the next best thing to combining queries. It would be simple enough to use, and it would eliminate the overlap (and distance calculation), which should mean that the database load is actually *decreased*.


    Anyway, just a pair of ideas about a subject that does not matter yet to me (but that does matter to many cachers). If you would care to comment, Elias, Jeremy, or whomever, I and my fellow GPX coders and users would be most humbly grateful. (And feel free to post that you want to postpone commenting; it'll make it easier for us to control ourselves... somewhat. icon_biggrin.gif)


    (Incidentally, they told me to ask if half-stars might be added to the pocket queries, since many of us would like, for example, terrain >= 4.5, or even a split at PQ1: <=3.5 and PQ2: >=4)

  7. Okay, the nice thing about GPX is that you can do all sorts of lovely things. The downside is that you need to know what's there so you can do stuff with it. Well, I will now remedy that situation, at least with regards to the cache type and log type strings.


    <gpx>  <wpt>    <Groundspeak:cache>      <Groundspeak:type>

    "Event Cache"

    "Letterbox Hybrid"

    "Locationless (Reverse) Cache"


    "Project APE Cache"

    "Traditional Cache"

    "Unknown Cache"

    "Virtual Cache"

    "Webcam Cache"


    <gpx>  <wpt>    <Groundspeak:cache>      <Groundspeak:logs>        <Groundspeak:log>          <Groundspeak:type>

    "Didn't find it"

    "Found it"

    "Needs Archived"


    "Unknown" (no icon on the cache page, only the admins can do it)


    (Now all you GPX application creators know all the type strings, which I imagine you might find as handy as I.)

  8. quote:
    Originally posted by gnbrotz:

    I am using ExpertGPS (ver 1.2) and am also only able to view a fraction of the .gpx file. My Saturday query (.loc format) came with 345 caches and was only 622 kb. Switched it to .gpx this morning and only have 47 caches when I open the file, even though file size is now 1.43 mb.

    This is a known problem with versions of ExpertGPS before 1.2 and versions of EasyGPS before 1.2.1. If you're having this problem, you need to download the latest version (which still might have the mishandled characters bug, but will definitely load all the waypoints and everything correctly).


    Latest version of ExpertGPS

    Latest version of EasyGPS


    (Note that the Groundspeak version of EasyGPS has not yet been updated past 1.1.9, so it will exhibit the missing waypoints problem.)


    Incidentally, if you haven't taken a peek at Watcher, you really ought to (if I *do* say so myself icon_wink.gif).

  9. (First, let me say that active-but-abandoned cache adoption is a very nice thing, and we in Louisiana have done that several times with excellent results.)


    Recycling cache IDs is a very bad idea. (Not only that, but it is, in fact, quite literally WRONG.)


    Cache IDs are serial numbers. Cache IDs are primary keys. Cache IDs are monotonically increasing. If you don't understand monotonically increasing primary keys, I would be more than happy to locate a nice book on databases for you. In fact, I'll buy one and ship it to you personally! (E-mail me an address and I'll get one out to you ASAP.)


    Anyway, trying to solve the theoretical exhaustion of waypoint names by changing cache IDs from a monotonically increasing primary key is, by definition, wrong. You can change the waypoint naming scheme; you can add a new field; you cannot recycle a monotonically increasing primary key.

  10. quote:
    Originally posted by alexm:

    You share source at all? I know a guy just up the road from you who's been DYING to dabble in developing a PPC app. Geocaching PPC apps a plus. icon_smile.gif

    At this point, the source is really messy and uncommented, but I'd be willing to clean it up and comment it enough to zip and send to someone on request, if I thought it might do some good. (Once it's just a little stable, I'll probably stick it up for the general public, but right now I'm just hacking away on it without worrying about packaging it, just to get it rolling faster.)
  11. So, your question is why does:

    “The Parasite Spawn” – Spawn #1(Hosted) by A Nord, Unknown Cache (1/1)
    <desc>“The Parasite Spawn†– Spawn #1(Hosted) by A Nord, Unknown Cache (1/1)</desc>
    in the Pocket Queries and not in the LOC files? The answer is simple: the .loc files generated by Geocaching.com use encoding="ISO-8859-1", and the Pocket Query .gpx files use encoding="utf-8". Now, on to assigning blame. icon_wink.gif


    The XML LOC files generated by Geocaching.com use the ISO-8859-1 character encoding because that's just what was there. Most XML parsers will be able to understand the ISO-8859-1 encoding, and EasyGPS understands it fine. When the GPX XML generation by the Pocket Queries was discussed, it was decided, and rightfully so, that the encoding used should be an encoding that can properly support the international character of geocaching (and which, incidentally, *must* be readable by every XML parser). With that in mind, the GPX files are encoded with the UTF-8 character encoding.


    Now, according to the XML spec, in order for a parser to be an XML parser, one of the things it *must* be able to do is parse UTF-8. Any parser that does not handle UTF-8 is, by definition, *not* an XML parser. EasyGPS claims to parse GPX XML files, but by virtue of the fact that it does not handle UTF-8, it does not actually have an XML parser. That needs to be fixed in EasyGPS.


    So, what is the problem? EasyGPS cannot handle the UTF-8 encoding that it is *required* to handle by the XML spec (and apparently it handles ISO-8859-1, which, incidentally, is not *required* by the XML spec).


    Oh, incidentally, Watcher (the GPX utility I am developing, as referenced in the Custom Search thread) does not have problems with the UTF-8 encodings, since it uses a true XML parser.


    [This message was edited by ClayJar on December 20, 2002 at 12:57 PM.]

  12. quote:
    Originally posted by Camping Hoosiers:

    I have installed Watcher... When I click on the Watcher icon, I get a box that says Watcher on the top and a white screen with a little pacman looking icon in there. I do not see how to open a GPX file. If I double click a GPX file it opens into EasyGPS. I do not see another way to open the file? Suggestions?

    Okay, I finally managed to get to a computer that would do the same thing. Turns out it is because of a too-old Internet Explorer. If you update your Internet Explorer, it will work fine.


    (Incidentally, if you run Watcher as "watcher.exe DEBUG", it will open an extra small window for debugging messages. You don't need to know that, but if you wanted to, now you do.)

  13. Okay, currently, the GPX-level description is simply:

    Geocache file generated by Groundspeak


    Watcher (the GPX utility I am developing, as referenced in the Custom Search thread) currently displays the filename of the GPX file being viewed. I would much rather have Watcher display the name the cacher chooses in the "Name this Search:" box when setting up the Pocket Query.


    Is it possible to change the GPX-level text to be the name of the Pocket Query? That would seem to describe the GPX far better than the generic text that currently exists, and the creator, author, and e-mail attributes and elements would still say where it comes from. I could then put the name and time of the Pocket Query in the window title, which would be much, much nicer than the filename.

  14. quote:
    Originally posted by The Hornet:

    p.s. Just a thought - how difficult would it be to produce a similar application for a Palm device (or even a Pocket PC)?

    If I had a PocketPC device, I'd definitely want to get right on making a somewhat similar application. Unfortunately, I only have an old Handspring Visor Deluxe, and I haven't found any similar development environments for that. Anyway, I suppose I'll just keep going here for a while, and I'll let the Palmists work on their projects. icon_wink.gif


    (The next things on the list are working on the HTML handling, adding distance-from-coords, and polishing off the user interface with a little open file button.)

  15. Remember you can also use [don't encrypt me] brackets... They'll make it a little more messy, though, but the stuff in them won't be encrypted.


    (So, you could do [

    1. ] item 1... [
    2. ] item 2 [

    ], but it'd leave brackets lying around.)


    Oh, one other thing to note. Your HTML is not quite well-formed. If you want to be more-or-less sure your HTML will display on all browsers (or at least the ones other than the one(s) you're using), you should be careful.


    should be


    (i.e. close the tags in the reverse order you opened them) Other than that little nit, it looks quite nice.


    (By the way, editing messages in here with

    in them is a royal pain in the everything. icon_rolleyes.gif.)


    [This message was edited by ClayJar on December 19, 2002 at 08:49 PM.]

  16. Okay, the next version is now out. Included is the ability to click the GCID to go to the real Geocaching.com cache page. Not only that, but you can click the *name* of the cache to pull up the basic cache page as saved in the GPX file. (Oh, and I updated the sort algorithm so that status and date sorts will sub-sort by ID, rather than leaving it random.)


    I still need to clean up the GPX-using basic "cache page" (especially handling HTML vs. non-HTML), but it's there to play around with for the time being. Also, I think I'll toss in the "Distance from X" column (and a place for the coordinates) as soon as I find the time.

  17. -1


    Apparently, there can be some caches that don't have stars. This is from Bonita Lakes (GC90).


    (You know, I think I may have to start maintaining a "SmokeTest.GPX" file will all the special cases we find, just so that we can be sure that we're all handling them all properly.)

  18. It should automatically pop up a "File Open" dialog for you to select the file. Did you use the install or just the -exeonly version? The install version adds one system file, but other than that, they're the same. If you didn't use the install, use the new one there now, otherwise, just use the new -exeonly version. Which leads me to a nice little segue...


    Watcher-0.1.5 is now available! Get it now at the usual place. You can now *sort* the caches! (And the lines are alternated white/grey for easy reading.) icon_biggrin.gif

  19. quote:
    Originally posted by Dekaner of Team KKF2A:

    This is great, just the type of tool I was looking for. Am I allowed to ask some questions and make some suggestions for future versions?

    I'm glad I got the gist of it right, and suggestions are always welcome. (Perhaps not replied to immediately, but always welcome.)

    I'm guessing that the icon on the far left indicates the status of the cache, current/temp-disabled/archived?

    Fuzzy got it basically right, but he missed one... the purple "dead-face" smiley (with x's for eyes and its tongue sticking out). That's for ones with "Needs Archived" as the latest log type. icon_biggrin.gif

    Is there anyway to link the GC number such that I could click on it and have it open a new window with that cache?

    Actually, what I'm wanting to do is make the GC number link to the actual current cache page (in a new window). The name will theoretically link to the cache page as it is in the GPX file. The logs will probably link to the logs. The status icons might link to a "status legend", but whatever.

    Can it be sorted from last find date so I can see the oldest first? (These are usually the ones in trouble.)

    I intend to make it sortable by any of a number of possibilities. I just wanted to get the first demo out right away, so I haven't started that part yet.

    Are the log icons most recent left to right or right to left? (This was a neat idea!!)

    Most recent to least recent, left to right. (So the first one as you read the line would be the first one as you scroll the cache page.)

    Overall I am very impressed and can't wait to see what's next! Thanks again!
    Well, I hope to get to adding the useful features soon. Got to go to a Christmas party tonight, so it may be a little while, but as you can see, it's not total vaporware. icon_wink.gif
  • Create New...