Jump to content

abcdmCachers

+Premium Members
  • Posts

    66
  • Joined

  • Last visited

Everything posted by abcdmCachers

  1. Thanks for the comment about CacheStats @barnold. Just thought I'd let everyone know that I released version 4.0 of CacheStats last week. This version incorporates the maploco maps I mentioned above, plus I fixed a few bugs and added some small features such as the ability to filter your calendar and D/T grid by cache type and by year.
  2. Yeah, sure looks like world66 has permanently shut down. Here's another alternative that looks pretty good: https://m.maploco.com/visited-states/ Nice to see there's still at least one other CacheStats user out there! It's been years since I've updated CacheStats, but I think I can manage putting out a new version that fixes this so you don't have to manually update the html. I've added it to my todo list. Doug
  3. Hi, I'm looking to team up with a New Zealand cacher. I've collected the necessary information.
  4. Planning to head out this afternoon for the WI info. Looking for a CT partner.
  5. LOL, you'd think after the first 20 or 30 times I'd be able to train myself to do the same thing. I guess I'll need to order your book.
  6. I tend to agree. In general, many of their link placements are puzzling to me. For example on my profile page (the one I see when I log in, not the public one), why is "your GPS" listed first above all else? This is the least useful item to me. Same with Geocaching with Twitter. I'd venture a guess that far more people generate a my finds query than geocache with twtter, so why not make it at least as prominent? That said, UI design is tough. If they make it more prominent on the "your profile" page, there could be unintended consequences (like people clicking it without really knowing what they just did). One small very easy improvement IMO, would be to rename the button. Sure, people know what a queue is, but it's kind of a techie term. Why not name the button to help explain exactly what it does, e.g. "Generate My Finds Pocket Query" or something like that?
  7. Add me to the annoyed camp as well. I must subconciously position my mouse over to the right edge when I start scrolling because I seem to hit it everytime. I'd prefer that it be turned off by default if possible. Keeping it turned on for the large map (where page scrolling is less necessary) is fine by me, and might be a good compromise to keep both the annoyed camp and nifty feature camp happy.
  8. Looks like you have it figured out, but for anyone else reading this thread, the instructions are on the CacheStats website but they're easy to miss. Look on the right side of the page in the More Information section. Instructions have been updated recently with screenshots showing the new way to retrieve the My Finds PQ.
  9. Dave, As author of CacheStats I'm totally amazed at what you've accomplished with the site. Good luck and hope to meet you on the trail or at an event someday. (Actually we've probably already met - the first event we ever attended was your mother of all breakfasts event). Doug P.S. I'm a little late learning about this news since I don't usually follow this forum closely. I only learned about this because I DO follow the web site forum. Have to follow that one to keep up on those pesky format changes that you mention!
  10. I think the addition of an optional distance field would be great. Some days you don't have time for a long hike, other days that's exactly what you're looking for. Having the ability to filter by distance in a PQ or even better, sort by distance in GSAK would be a great help. Yes, there are variables like where people park, and whether they take a direct route vs. a more terrain-friendly route. That's one argument for keeping it optional. But even having a general idea would be helpful. Also, that issue could be partially addressed by not requiring exact distances, and instead choosing from built-in maximum distances (e.g. just as an example <100 feet, <quarter mile, <half mile, <mile, <2 miles, etc. The exact set of choices would need some thought. The set of choices might even be controversial too, just a wild guess ). The problem with relying on the existing "takes less than an hour attribute" is that it's not fine-grained enough. Using that scale, there's no difference between a park and grab and a 1 or 2 mile hike. Just another opinion, thanks for reading.
  11. In another topic, Chysalides made the following statement. I thought it would be better to start a new thread rather than reply in that one. Does anyone know about logging from the iPhone App? I have heard (but don't know for sure) that when you log a find from the iPhone, it uses the actual time, not 19:00 as stated above. If so, is the time converted to UTC equivalent, or is it local time without any conversion? More precisely, my question is: how will the time be represented in the My Finds PQ? I ask because it's been challenging for CacheStats to report the actual date of the log. If it's true that the log date/time for iPhone logs is actual and not 19:00Z, then should I convert what's given in the GPX file to local, or take the date as given? I would hope what's in the GPX file represents local time. Unless I'm totally confused (which is probable because my head hurts when trying to sort this all out), if it gets converted to UTC, I would first have to determine the timezone of the cache location, and then convert UTC to that timezone to find the date of the log. But what if they log it a day later, but they correct the date as you can do when logging on the web (is that doable on an iPhone?). What time will be shown in the GPX file for that scenario? If what I heard isn't true and the iPhone logs the same way as when logging on the web, then I guess the above is moot. Hoping someone can straighten me out and give a definitive statement about how it currently works (and if it's likely to change in the near future). Thanks!
  12. I agree such a feature would be nice. Before geocaching.com switched to Google maps, their maps had an option to show archived caches. I miss that feature since I'm always thinking, didn't there used to be a cache near here? CacheStats has a feature that addresses this issue to a small extent (disclaimer: I'm author of CacheStats). You can search for caches that you have found, regardless of their archive status, that are near any given cache. The key phrase here is "caches that you have found". Since CacheStats works off of the my finds pocket query, it will only show archived caches as long as you have previously found it. More info here: http://www.logicweave.com/Blog/post/Versio...ache-icons.aspx Not exactly what you're looking for, especially if you haven't been caching long, but as the years roll by, I find it handy to have. I guess another option would be to keep a GSAK database. If you didn't purge out archived caches, you could do something similar. Doug
  13. I've often thought of making something like this as an adventure-style game (i.e. text only, or limited graphics) as part of a puzzle cache, but have never found the time to put it together. You might be interested to know that Jeep made a game a couple of years ago to help promote their brand: http://www.jeep.com/games/geocaching.html As I recall, you navigate to the cache sites (in your Jeep) and find as many as you can in the time alloted. Didn't really capture the finer points that you are proposing.
  14. I'm guessing if geocaching.com ever expanded the existing Friends feature to be more than it is now, that might interest them more than a designated forum for kids. I'm thinking something along the lines of facebook/twitter where you could update your status which gets sent to your friends, and likewise view a feed of status updates from your friends. Geocaching.com could even automatically post finds to your update stream, although I'd be against that. I'm not a big fan of the automated Twitter messages they have now (too much noise). But an optional automated weekly summary update would be cool so you could keep track of what your friends have been up to geocaching-wise. Just some thoughts.
  15. Thanks for your feedback. I finally had time to look into this in more detail. CacheStats was indeed reading the new date format in UTC and translating it to the local timezone. So the logs timestamped at 19:00 for the CacheStats user in Auckland (UTC+12) were translated to 07:00 the next day. Easy enough to fix. This leads to my next questions. Almost all of the log dates are 7:00 or 19:00 depending on how old they are (or 8:00/20:00 depending on whether the date falls during DST or not). But I've seen a couple of instances where this is not true. Here is one example. Notice the time stamp in the GPX file is 01:44:06. Are there other logging methods (e.g. via WAP or iPhone) that record the actual time? Or was this a temporary glitch in the logging system? If there are other logging methods that use the actual time, what does the time in the GPX file represent? The time of day in Seattle that the log was created or the time of day in the user's local timezone? (Expressed in UTC of course). Thanks again.
  16. I'm hoping someone can definitively explain log dates in the my finds PQ. I notice in an older PQ I have, log dates look something like this: <Groundspeak:date>2008-08-21T19:00:00</Groundspeak:date> Now, there is a Z appended after the time. I have to plead ignorance here, but doing a little resarch, it appears to be UTC time (formerly GMT), correct? I'm author of CacheStats and I have a user where half his dates are reported correcty and the other half are off by one day. Seems older caches the time is 07:00:00Z and newer caches are T19:00:00Z and some are T20:00:00Z. I'm guessing CacheStats is incorrectly translating the 20:00 to the next day. So my questions: - Should I be translating the time from UTC into some other time zone? If so, which one? Or should I not translate at all and just take the date of the find as whatever is in the date portion, regardless of what the time of day is? - Any significance to the different times logged (7:00 vs. 19:00 vs 20:00)? I'm thinking 19/20 is probaby due to DST. What will be the standard going forward? - Somewhat related, I've also noticed and reported (http://forums.Groundspeak.com/GC/index.php?showtopic=237318&hl) that some times in the GPX file are random (i.e. not 7, or 19) and the day off by one. Anyone know if that has been resolved? - Was this change communicated to GPX developers? If not, again I ask that a reliable communication platform be set up for this type of thing. In the past I suggested taking down the pinned "GPX application developers" thread which is worthless and misleading, and replace it with a admin-only thread that diseminates this info. Thanks for any info you can provide.
  17. I don't think this one has been reported yet based on my quick scan through 6 pages of comments. When looking at TB history for a cache, some location icons are missing. For example, on this page, the icon for ToastyTubes EEPROM is missing: http://www.geocaching.com/track/search.asp...d2-b744a888871c Looking at the html, I see it's using: <img src="new_/images/track/loc_user.jpg", while the next one under it is using the same icon without new_.
  18. I'm author of CacheStats and I'm posting on behalf of a CacheStats user. The date of the log in the GPX file does not match the date of the log shown on gc.com on several caches for this user (off by one day). Is this a known issue? If so, any resolution? (I thought I remember reading about it in the forums earlier, but can't find the post). For this user, are there any workarounds? I suggested editing the log date to some other date, and then re-editing to the correct date. Don't know if that will work. You can contact me directly if you want the specific logs in question. Thanks, Doug
  19. I recently placed a cache on what I thought was public property, but it's owned by a division of the county so the cache reviewer won't approvie it until I receive permission from the land owner. All I have to go on is information from the county online GIS system which gives me the owner's name (County Institutions) and an address. I tried finding an appropriate phone number or email address, but didn't have much luck so I decided to send a letter. Strange feeling, writing a letter. I just sent it on Thursday so we'll see what happens. Since you asked, here's the text of my letter. It's not great, but maybe it can serve as a starting point for you or someone else. Writing isn't really my thing (I tend to be too verbose and add a lot of parenthetical comments), so if people want to suggest improvements that would be great. If there are other sample letters out there, I'd also like to know for future reference.
  20. I agree that a heads up on this type of change would be much appreciated. As author of CacheStats, I think CacheStats will be able to handle the GPX changes, but I can't easily test it because I did a my finds PQ earlier this week. Having even just a short notice would be really nice. Groundspeak, how about replacing the very old pinned discussion in this forum (the one that says shout out if you're a GPX developer), and replace it with a GPX announcements thread? Advantages: easy for GPX developers to follow via RSS, and no people posting asking to be added to the non-existent mailing list. Even if you can't give prior notice, but instead post to the announcments at or shortly after the release, that would still help out because it's one location that people can go to and less likely to get missed as can happen in long release notes. Thanks for considering this.
  21. Lots of great ideas in this thread. One of ours that I like is Old Jersey. We borrowed the idea from Games Magazine. Took us a long time because we had to create custom fonts.
  22. Maybe we could adopt Scott Adam's (creator of Dilbert) term, "induhvidual" (pronounced the same as individual, but spelled with "DUH", as in clueless). According to wikipedia, "...members are characterised by their superior intelligence and good looks, whereas non-members ('induhviduals') suffer from idiocy and lackluster charm." That term works pretty well, no? Oh wait, maybe not, "my cache was individuhualized" doesn't really work. Oh well. I may be remembering wrong, but when I first started in 2004 I think "geomuggle" was the preferred term. I thought it was funny, and I actually like that a little better than muggle by itself. Not sure when it lost the geo prefix.
  23. We've had pretty good luck with the Swarm of Bugs: http://www.geocaching.com/track/details.aspx?id=155655 We made it clear that people should get owner's permission before adding a new TB to the swarm. So far we haven't received any complaints.
  24. abcdmCachers

    MyFinds PQ

    Hi Raine, I'm author of CacheStats and I had a user report this problem to me, but he also reported that his zip file contained 40 separate gpx files. He has a very high number of finds, so I wonder if this is a new performance tweak that the statistics software applications will have to support? Thanks, Doug
×
×
  • Create New...