grnbrg

Drum roll, please..... Parks Canada Welcomes Geocachers: Come Explore With Us! grnbrg.

Sweeet! That works. I didn't now the "tag=" component wouldn't get stripped. Thankyouthankyouthankyou! grnbrg.

The html tidy adds that, and enforces it's placement before the href="" component, if you try to add it yourself. It tells search engines not to follow the link, so that spammers can't use cache listings to boost the page rank of their viagra sites. ETA: And the href="..." component is too long, and wraps anyway, when the URL is a cache link. grnbrg.

Mozilla Seamonkey (same engine that Firefox uses). And the rendering is correct -- there is whitespace (a linebreak) between the ">" of the anchor and the first character of the cache name, so " Cache Name" is how the current code should look. I just can't find a way to eliminate the linebreak at that point. If I use: sample text "<a href="http://www.shorturl.com">Cache Name</a>" sample text the URL is short enough that it doesn't wrap, and the text displays correctly. I could (and might yet) include the quotes as part of the hyperlink, or leave them out entirely, but thought I'd bring it up as a bug report nonetheless. Eliminating the quotes within the tag (ie: <A HREF=http://www...>...</A>) doesn't work, BTW. The html tidy code puts them back. grnbrg.

Depends how you define "work"... I'd like the quotes to remain outside the hyperlink... "Cache Name" not " Cache Name" or "Cache Name" grnbrg.

I've been putting together a description for a new cache, and have run into a (admittedly minor) issue with the html tidy output... I've entered the following html: While you're here, you might want to give "<a href="http://www.geocaching.com/seek/cache_details.aspx?waypoint=GC12345">Cache Name</a>" a look. Which should result in: (Note the placement of the quotes.) The html code produced, however is: While you're here, you might want to give "<a rel="nofollow" href="http://www.geocaching.com/seek/cache_details.aspx?waypoint=12345"> Cache Name</a>" a look. Which displays as: (Again, note the quotes.) It looks like the html tidy code his putting a hard line break after the closing angle bracket of the anchor tag, which (at least with my browser) results in a space being inserted at the start of the anchor text. Is it possible for the hamsters to be trained that the ">" character should be treated as non-breaking? Thanks! grnbrg.

Huh? 0.1 statue miles is 0.0869 minutes latitude anywhere in the world, and from 0.0869 to thousands of minutes longitude depending on your latitude. Ugh. Ok, pass me the stupid hat. However, it doesn't affect the example, though. I could pick a point in 350x350 square, and use 90 as a search radius just as easily. I just don't think that pinpointing a location with a few guesses is as easy as some are making out. Anyone want to try? grnbrg.

I've seen this topic pop up before, and I saw a similar response. I call BS. Regardless of whether such a checker is a good (or even feasible) idea or not, I don't think that it's at all easy to pinpoint a final or intermediate location with a few guesses. I've picked a point at random within a 500 by 500 grid. Since .1 miles equates to about 0° 0.1333', let's call the radius just "133". Post (or PM me) guesses in sets of 5 (or less if you'd like), and I'll give you "yes/no" answers if the guesses are within a 133 unit radius of my chosen point. If you want to guess at the point at any time, I'll tell you if you're within 13 units (about 50 'feet', giving a search area 100 feet across). I'd guess you'll need 15 or 20 ranging guesses before you can get close enough. Keep in mind that the last time I saw this discussed, the idea was developed to the following: Only premium members can check co-ordinates. An existing point within .2 or more (ie: *more* than the .1 mile limit) would result in a response of "There might be a cache too close to this spot. Check with your reviewer.". Only 1 (or 2 or 3 or whatever) check allowed per member per (day/week/month). This would put fairly firm limits on being able to carpet-bomb a location. So, want to play battleship? 1,1 is a "miss". grnbrg. Edited to add: (-100, 50) or (600,200) are reasonable ranging guesses, but my point is within ([0-500],[0-500]).

I received the "Bolton, Canada" U4D TB in January, and dropped it in River Path in Bolton this afternoon. No snail mail involved, although I sat on it for a while... Traded it (in the same cache) for another U4D bug going to Lativa. Don't think I'll make that delivery in person. grnbrg.

Well, this one is for the Manitoba Geocaching Association. Someone suggested it as an idea, and it was an easy one to realize. I put the image together, and added it to our Cafe Press shop -- the MBGA gets a whole dollar for each sale. I did see AV's design, but only after creating the posted image. The main idea was to print up a few dozen permits and sell them to our members for $2.00 or $3.00 each. The sticker at CP was added so that if others outside the MBGA were interested, we wouldn't have to deal with shipping. And a couple of micro cache labels were added to pad it out. If people want to make their own, it's an easy project, but having a single vinyl sticker printed will cost $5-$10. Or they can buy this one online for C$7.80 or so. grnbrg.

How about this for a system: Premium members are allowed to recommend (N=5 or N=10% or whatever) caches. No rating, just "I liked this cache." Either on page load, on request, or nightly, all the "recommend lists" that mention that particular cache are totaled, and the top 5 (or 3, or 10, or a random 3 of the top 10) are returned as "Cachers who liked this cache, also liked..." results. The result would be that caches that are exceptional would get a *lot* of advertising, and caches that are interesting, but not yet well known would be flagged in the more well known caches. Also, since someone who is likely to recommend a particular cache type is probably more likely to recommend others of that type, this gets around the "I hate puzzles, I don't want to see highly rated puzzle caches!" argument. My 2 cents, anyway. grnbrg.

I like this. What would be the useful rating that would put it on the cache listing? Over 60%? It already sorts for usefulness. I'd suggest the bookmark show on the cache page, unless It's been rated by 5 or more people. It has a "useful" percentage of less than 50%. This would allow unrated bookmark lists to show up, (I suspect the vast majority of bookmark lists are unrated) and the purely negative bookmark lists will quickly aquire a "not useful" rating from annoyed cache owners that will push them off the cache page. It might also make sense to use a link separate from the current "more" link -- "Low ranked bookmarks", or something. grnbrg.

Do you run a Linksys router/firewall? Some Linksys products don't play nice with irc chat servers... If you do run a Linksys with the firewall enabled, try to connect after disabling it. Not a good idea to run for any length of time like this, but it will tell you if that is the problem... grnbrg.

Well, it's about as far from Oakville as you can get, and still be in Ontario, but I just placed two canoe-access caches near Kenora last weekend.... (plugplugplug) Like a Troubled Bridge over Water (GCXRN9) Little Scovil. Little Culvert. (GCXRNA) These two are about three hours from Highway 17, and make for a really nice weekend trip. (There is also an Manitoba Geocaching Association coin as a FTF in "Troubled Bridge".) Enjoy! grnbrg.

... to find out that the cache is 150 feet from the final stage of a multi. I think I started the last thread for this particular feature request. [] BTW, there was post from Jeremy in that he has added this to the "When I get time to think about it (and maybe do it)." list. grnbrg.

As above to Raine -- I'm an idiot. The bookmarklet works for me, as I find it easier to use Google's interface to muck around until I've got a route I like, then cut and paste the data, rather than the seach co-ords. Whatever works. Yeah, my style thing is a horrible (and not very general) hack. But it solves a problem I thought I needed to solve for this, and have wanted on occasion to solve for other stuff -- promoting a track to a route. (ObFeatureGrovel: Converting between tracks and routes would be nice!) Thanks for a most excellent product, BTW. grnbrg.

Ever have one of those days.... Looks like I missed just using the "Full" tracklog. Probably because I assumed it would truncate, but you appear to optimize the submitted route to something reasonable before truncating. My bad. And my inital attempts with GPSBabel may well have omitted the gpxver="1.1" option. I found references to it, but couldn't seem to get it working. So I decided the problem was that I was feeding tracks, not routes.... In any event, the "Full" tracklog from GMaptoGPX results in a correct (ie: matches the roads travelled) GC.com route. No additional massaging required. DOH! grnbrg.

There has been a lot of focus on using Google Earth to create routes. I've worked out a series of steps that can be used to use Google Maps to do so.... The first step is to switch to Firefox, and add the GMaptoGPX bookmarklet to your toolbar. Information on GMaptoGPX can be found at www.elsewhere.org/journal/gmaptogpx. Next, go to Google Maps, and use the "Get directions" option to create a route from one location to another. Click on the GMaptoGPX bookmarklet, and after a moment, you'll be presented with the content of a gpx file with the specified route. Ignore this. If you use it, you'll find that it's actually a very coarse route, not usefull for what we want. Click on the "Full" button, and the XML data will change. This data specifies a full track of the route, and may be quite large. Copy (cut and paste) this data into a file, "route.gpx" for example. You now have a problem. You have a trackfile that may run to several thousand points. Geocaching.com currently does not accept track files for routing. And they'd only look at the first 500 points anyway. Enter GPSbabel. GPSbabel can be found at (surprise!) http://www.gpsbabel.org/. GPSbabel, however, does not by default have an ability to convert a track to a route. It is, however, very configurable! Save (again, cut and paste) the following: # gpsbabel XCSV style file # # Format: "GPS Babel tracktogpxroute filter" # Author: grnbrg@grnbrg.org # Date: 5/07/2006 # # DESCRIPTION Convert a track to a GPX 1.1 route. # FILE LAYOUT DEFINITIIONS: # FIELD_DELIMITER SPACE RECORD_DELIMITER NEWLINE # # HEADER STUFF: # PROLOGUE <?xml version="1.0"?> PROLOGUE <gpx version="1.1" PROLOGUE creator="GPSBabel tracktogpxroute filter" PROLOGUE xmlns="http://www.topografix.com/GPX/1/1" PROLOGUE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" PROLOGUE xsi:schemaLocation="http://www.topografix.com/GPX/1/1 [url="http://www.topografix.com/GPX/1/1/gpx.xsd">"]http://www.topografix.com/GPX/1/1/gpx.xsd">[/url] PROLOGUE <rte> # # INDIVIDUAL DATA FIELDS: # OFIELD CONSTANT, "<rtept", "%s" OFIELD CONSTANT, "lat=", "%s" OFIELD LAT_DECIMAL, "", ""%f"" OFIELD CONSTANT, " lon=", "%s" OFIELD LON_DECIMAL, "", ""%f"" OFIELD CONSTANT, ">", "%s" OFIELD CONSTANT, "<name>", "%s" OFIELD INDEX, "", "%04d" OFIELD CONSTANT, "</name>", "%s" OFIELD CONSTANT, "<cmt>", "%s" OFIELD INDEX, "", "%04d" OFIELD CONSTANT, "</cmt>", "%s" OFIELD CONSTANT, "</rtept>", "%s" # EPILOGUE: EPILOGUE </rte> EPILOGUE </gpx> to a file (tracktogpxroute.style, for example). Now run the following command: gpsbabel -i gpx -f route.gpx -x simplify,count=500 -o xcsv,style="tracktogpxroute.style" -F PQRoute.gpx The resulting PQRoute.gpx file can be uploaded to Geocaching.com, and will provide a nice, tight match to the route you intend to travel. Enjoy! grnbrg.

Just a relvant followup regarding our CITO event this weekend.... The event itself went very well, with four different caches being placed and cleaned up -- nearly 70 bags of trash collected, and mention in the local paper, and even a brief spot on the news. However, because the organizers weren't sure that the four CITO caches would be published at a given time, they decided not to mark them as 'active', and just distributed printouts of the unreviewed cache pages at the initial meet-up on Saturday morning, letting people know that the caches would be published in the next day or two, when the reviewers got to them. Three of the four were published properly Sunday morning. The other turned out to have multi-cache waypoints nearby, and needs to be moved. Admittedly, the organizers could have done this somewhat differently, activated the caches before the event for review, but they didn't. Giving the owner some control over the release (such as being able to specify a release time, as has been suggested in this thread) would have prevented this. grnbrg.

What are these reasons???? Two concrete examples: We're having a CITO event on Saturday, and in conjunction with this, there are four new traditional caches that will be the 'targets' of the CITO drive. Another organization held a "Hide and Go Cache" event, where members hid caches in a week or two leading up to the event, which were published en masse. And a few speculative examples: I could run a cache-based contest where I want to publish several game caches, one at a time at specific (ie: daily, or weekly) intervals. I might want to create an aniversary/birthday/holiday cache, and want it to be published on a specific date. I might want to give more people a shot at the FTF, and publish on a Saturday afternoon. I might want to publish a cache at a time where I know *I* can show up as it is published to laugh at those trying to find it. (An enjoyable passtime, actually...) Yes, all of this can currently be done by nicely asking the reviewer to publish at a specific time, but some of the reasons are hardly compelling, or important, just 'nice'. And fufilling some of them (like the 'Hide and go cache' event) can be a fair sized organizational burden for the reviewer. grnbrg.

Which is the primary reason for the feature request. There are a number of very legitimate reasons to have "all 17 caches published at exactly 7:04am on Saturday morning", and this is an unreasonable request to make of the reviewers. The reviewers job is to make sure all submitted caches are within the published guidelines, and are not too close to existing caches. Anything beyond that is an inconvenience that they need not worry about, although most are quite happy to accomodate. Since *when* a cache is published is not likely to somehow change whether or not a cache *should* be approved, why not give the option to do so to the cache owner, who arguably would have more interest in when a cache is published than anyone else? grnbrg.

Yup. Which is why I think this is a useful feature. If I *want* a cache published at exactly 10:07 am, or if we're kicking off a cache-hiding blitz event, and want to publish 75 caches at 8:00 am on a Saturday morning, it would be nice to be able to do it myself, without having to burden the volunteer reviewers. And I prefer to get approval for my caches before I place the container, because there is a chance that I'll get a response like "Sorry, but there's a multi-cache cache 100 ft from there. You'll need to find another spot." Giving the cache owner the ability to decide when a cache goes public will increase the flexibility for placing caches, and will *reduce* the work required by the volunteer reviewers, who will no longer have to deal with "Please don't publish this before Saturday, as it is related to Event Cache GC1234, and we don't want to give anyone an unfair advantage." requests. grnbrg.

Would it be possible to change the cache approval process to allow the owner to decide when the cache is revealed to the public? ie: Allow a cache to be placed, reviewed and approved by reviewer, but have the final step that allows the cache page to be visible, instant notifications to be published, etc be (even optionally) at the cache owners discretion. This would allow caches associated with a particular event to be published en mass by the event organizers without needing to co-ordinate with the reviewers. It would also allow individual users (Ok, me. I like doing things this way...) to plan out a cache, develope the cache page, go through the full review process (in case there are any changes required) and once the cache is approved, place the container(s) at their sites. Right now I get to race the FTFers to the spot. This could be done (for example) by adding a "Ready for Review" attribute, similar to the current "Cache is Active" attribute, and allow reviewers to see any cache marked "Ready for Review", regardless of the "Active" flag. The current logic that prevents general users from seeing caches not marked Active would remain. I do realize the programming headaches such a change might entail, but it's a feature I think would be well recieved. Thanks! grnbrg.

Would it be possible to modify the instant notifications email to include the co-ordinates? I have these notifications automatically forwarded to by phone via SMS messages, but need to get to a computer to actually get the information to transfer to the GPSr.... I could probably write a script that pulls the cache URL, and adds the co-ords to the SMS message, but that would be a pain. And probably technically naughty. Just a suggestion. grnbrg.