Westacular

In the area where I was seeing a problem (the trails between GC27B2T, GC1YTFM, and GC24AR4) the map was offset 50 m to the south... consistently. Longitude was accurate, and my Oregon was zeroing on top of caches, so I don't think the problem was on my end. I expect there might have been a weird error when the tracklogs were generates, or some issue in conversion? I'd volunteer my tracklogs but they'd require more cleanup (eg editing out the bushwhacking/cache hunting/other random wandering) than it's probably worth. Also: I don't mean to sound negative! These maps are incredibly handy, and I'm glad someone took on the initiative of gathering and organizing all this data into a useful form. I only mentioned this issue because it looked like it could be the sort of distortion that might have a simple fix.

They were indeed handy, however... was it just me, or was there a problem with the mapped trails to the NE of the centre? The shapes of the trails were accurate, but not lined up... there was a significant systematic bias in the latitude. I'm guessing some sort of datum mismatch?

Well, almost fine... A couple nitty-gritty issues: Ibycus' server is sending the torrent file as Content-Type: text/html, which means browsers try to read it directly (and display a bunch of gibberish) instead of offering to save the file. Also, the torrent rather unnecessarily lists 63 different trackers... only 4 of which are responsive and actually tracking this torrent.

Note that what I'm talking about only applies to ordinary PQs; along-a-route and bookmark queries probably behave differently.

The focus on sorting could be a bit misleading... the issue isn't so much the sorting, as it is, WHEN during the process of querying the database is the list of caches truncated down to 500 or 1000, and what their sorting is at THAT point. That said: I just ran a few tests, and the truncation appears to be the final stage regardless of query. So, whatever the final sort order for the query is, it's the caches at the end of that list that will fail to appear. If the query involves a radius from an origin -- which applies to almost all of mine, and I expect most in general -- then the final sort order is ALWAYS the distance from that origin, and the results you get will nicely cut off at a certain distance (ie giving the 500 or 1000 closest to the origin), regardless of what the actual radius limit is set to. I just tested this by previewing a couple of "placed between these dates" queries with the radius set to a few hundred kilometers from home coords. On the first, all of the 500 results were within 158km, and sorted by distance; on the second, where I expanded the date range by a several months, all of the 500 results were within 82km. The only time this isn't the case is when a "from origin" filter isn't set, and "within [country/state/province]" is used instead (since at least one of the two options must be used). And yes, in that case, caches are sorted and truncated based on the cache ID (which roughly correlates with the cache's age, though there are exceptions.) I haven't tested this with more complex combinations, but I expect that any other aspects (like cache size/type/attributes) would be part of the initial database query and wouldn't affect this behaviour. So: 1) If you're searching for caches, and you include a radius and an origin, you'll always get the closest ones to that origin, even if the radius is set too large and you run into the number of caches limit. 2) If you don't set an origin (which necessarily means you're searching within a preset region), they will be sorted according to cache ID, and you'll get the first 500 or 1000 or whatever based on that. 3) Just because you CAN enter a huge radius doesn't me you should -- the servers will have to do all of the additional processing a wider radius requires, but you won't get any more actual caches from that. So if you want to overestimate it, don't do it by a huge amount -- it will just slow things down and possibly break them. This behaviour makes sense, and I think is generally the right way to do this... although some more transparency or feedback to users about their queries would certainly be welcome.

Oh! That's weird. Those cache's definitely aren't members only; not sure what the problem was. I've got an Oregon as well, and just tested by using "send to gps" with them. The descriptions showed up fine. Is this just happening for certain caches, or everything you've tried?

If I'm understanding this correctly: the member's only caches show up when you're looking at the online map, and the little caption box that comes up when you click the icon doesn't have any indication that it's members only, and your workflow is to click "send to gps" from there, which ... fails silently, or only downloads a stub description saying "premium members only"? I just did a little test query; there's just seven in a 50 km radius of town: GP History Cache by Lunchbox (GC1C9X3) Ferris Buehler's Day Off by Tons_Of_Fun (GC1NCZF) The Fastest Paperboy In Town by Tons_Of_Fun (GC1NDTG) Five Mile As The Crow Flies by PatchyPooh (GC27AXP) All Nestled In by PatchyPooh (GC27AYC) šterkovne skrýš - GPA CAR III by Team Three Boys (GC1YAFR) 7077 by PatchyPooh (GC27DH7) Premium Members Only caches used to be indicated with a differently-coloured icon for the cache type. It appears that when Groundspeak switched to using that little person icon, they neglected to alter the map view caption boxes to include such indicators there. If you search for caches via the table listing instead of the map, you'll see the indicator. I'm surprised that it shows members only to non-premium members at all. I figured they'd just be filtered out entirely... I guess Groundspeak wants to show you what you're missing, in hopes that it's incentive to upgrade? (To me, all the additional website features are far more compelling reasons than gaining access to a tiny handful of additional caches.)

[edit: double post.]

I think a big part of the desire for this feature is directly related to the number of power trails that have started appearing. Regardless of ones' opinions on power trails, I think most can accept that they're not for everyone: it's an aspect of the game that many geocachers aren't interested in. The problem is that power trails involve large numbers of caches, which fill up PQs, and there's no efficient and effective way of filtering them out. They usually involve more caches than one should reasonably expect someone to ignore by going through them all one-by-one, and using tools like GSAK doesn't get around the problem of them filling up PQs. Things that would work, to various degrees: 1) adding "power trail" attribute 2) adding the ability to bulk-import a public bookmark list (eg into your ignore list), or the ability to bulk-ignore caches by checking them off on a search page. 3) adding an "ignore all caches from a given user" feature. Any of these options would be much better than the current methods available. Power trails are mostly made of up micro/small caches, with D/T <= 2, and you could filter those out, but: Currently, when defining a PQ, everything has an implicit AND. This means you can't set up one to find everything EXCEPT low-d + low-t micros -- and simply filtering out one of those properties would remove some interesting or unusual caches; e.g., I'd like to still see a D:1.5/T:5 micro cache located at the top of a tree, and also an urban 4/1 micro with an exceptionally clever hide. Even then, things like 1.5/1 micros I don't mind on their own -- they can be a nice break while biking through town, for instance -- but I have no interest in ever spending several hours walking a trail picking up dozens of identical, simple caches every 200m like clockwork. It seems clear that there are many others who feel the same and would love to have a convenient method to ignore this trend.

Oh, yeah, of course it has to be micro. He meant any data capacity. (i.e., 1GB, 4GB, etc.) Sometimes devices have odd limitations, where they can't support a card larger than a certain capacity -- the Oregon 450 does not have this problem.

I've always been entertained by that aspect of night caches: typically, you don't need the GPS to find the cache -- you need it to find your way BACK, after losing all your bearings because you've been spinning around in circles in the bush searching for that next marker.

I was in Calgary a couple years ago, and had a fantastic time doing GCRZKF "They Only Come Out At Night" with a couple of new-to-geocaching friends. It's an excellent cache, and although it's been moved and adjusted in the time since I found it, the recent logs indicate that it's still great. And Keith is right, when it comes to hunting firetacks, your basic entry-level LED headlamp (which tend to be rated around 25-40 lumens) is more than enough. The key is having the light source close to your line of vision; the markers are often VERY retroreflective in nature.

Saw this thread, decided to give the puzzle a peek earlier this evening. I spent a bit too much time on it but managed to get the solution in the end. Well put together, Hooligan. In hindsight the latter half of solving this should have been much quicker -- the answer was staring me in the face but I refused to think it could be that simple. I think there's enough hints in there now to make this quite feasible. The clues are all there in the text.

Not really surprising; the devil's in the details when it comes to efficient routing, and it requires some hidden variables about the mean effective traffic speed that can't be inferred just from the road's location and size. Until this thread, I didn't even realize that the format for routing data in Garmin maps had been reverse engineered? It would be neat to see some other things use this. For example: when biking or walking somewhere new, it would be awesome if I could have the GPS give me turn-by-turn directions for the on-road segments without constantly complaining when I'm on a non-road multipurpose trail (of which KW has a few, and are often more direct and faster than any road). This is mostly wishful thinking, though; I doubt Garmin will be adding routable trails to its offerings anytime soon, and I wouldn't be surprised to learn that the units cannot bridge two different mapsets when performing routing (which would mean that even if, say, your Ontario Trail Maps were routable, it wouldn't help much.)

Oh, I hadn't seen this yet... must be just outside my notification radius for new caches near my parent's house. I should make a visit the next time I'm over there in the evening.

The OpenStreetMap project looks like it's made a ton of progress, and there are both pre-made Garmin maps based on it and detailed DIY instructions: http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin

Probably also worth noting that the x50 Oregon models have separate firmware with distinct version numbering, and afaik, they have supported multiple .img files since launch.

I grew up there, and there's always been populations of coyotes in the forests, and farmers have been known to lose sheep to them from time to time, etc, but I've never heard any stories of them attacking humans. Yes, it's disconcerting when they start wandering into subdivisions, and you should show some caution, but unless there's been a specific warning, I wouldn't avoid trails because of it. That said, I haven't been following the news around there, and I don't know any specifics of the current situation.

Was this a normal cache or a travel bug hotel? I think the etiquette differs when it's a hotel. Also, in general, I think it's important to consider how long they might've sat in the cache. If you're the first person to visit it in six months, I think all of the TB owners will be very thankful you decided to put them back in circulation.

Hehe, I have a very similar story -- though with the helicopter and sound of gunshot, yours trumps mine http://www.geocaching.com/seek/log.aspx?LU...45-3818abc13847

The first step for someone who's curious about the hobby but doesn't know anyone that's already into it is probably to go to the site to check out how many are in their area. Which, they soon discover, requires registering.

Tempting! But how much leg room is there in one of these? I'm 6'2" and it looks like that might be a problem.

The most popular Bittorrent client for the Mac is Transmission http://www.transmissionbt.com/ Have you looked at http://www8.garmin.com/macosx/index.jsp RoadTrip is the closest equivalent to MapSource on the Mac, and you can use MapInstall if you just want to get the maps onto the unit. The most annoying thing is (although I'm not certain this is still true) all of Garmin's Mac apps use a different format for the map data, so unless someone has already posted a Mac-ified version of Ibycus Topo, you need to download it, install it on a Windows PC, run Garmin's MapConverter tool (http://www8.garmin.com/support/download_details.jsp?id=3897) then copy the file that outputs to your Mac to install the maps there. Personally, I just have a Windows partition on my Mac that I use through VMWare Fusion ... and almost the only things I use it for are GPS-related. (ie, GSAK and MapSource)

That's a good point, but personally, I have no intent of ever buying one of those preloaded cards, so it's not an issue for me.

When you can get a 4GB microSD card for less than $10, and you don't expect to use the US Topo maps, it's hard to justify the price difference for the 400t. I have an Oregon 300t and I have no regrets choosing that ... and I also haven't had any need to put in additional memory (yet); the built-in space has so far been plenty for City Navigator NT and ibycus's topo maps.