Enchanted Shadow

Good point. Perhaps it's worth a few other people calling Garmin tech support - it wouldn't be the first time they gave out incorrect information. That's the beauty of it - it finds by name regardless of distance; it's simply alphabetical. If you've got custom POIs, you might want to find something 50 miles away - Find by Name would bring it up in seconds. But if you used Nearest Containing, you might as well go grab lunch - and that's assuming it finds it at all. It all depends on whether you're searching for something relatively unique or not. If you want to find a Staples, than it's worthless, true enough.

Oh, this sucks. I just spoke with Garmin, and after researching the issue, they told me that the NT editions of their mapping software lose that functionality. Which means that you have to choose between more maps or the ability to find by name. So much for "new technology".

CNNA 2009 NT. And I find it interesting that you're seeing the "Find by Name" option at all, whereas I don't have it on any of the POI searches.

At first, I thought they deliberately removed this feature (partially because they did exactly that for Custom POI searches). But now I'm wondering if it's a bug.

And which unit and firmware version do you have? No, "Nearest Containing" is different for two reasons. 1. It only looks near your current location (or reference), so if what you're looking for isn't nearby, it will say there are zero matches when that's not true. 2. It looks for your entered text anywhere in the name, whereas "Find by Name" assumes you're typing from the beginning. That means that "Find by Name" will come up with something in five seconds that might take ten minutes for "Nearest Containing" to find, assuming it's close enough for it to find it at all.

I have a Garmin 76 CSx and City Navigator - and ever since I updated to firmwares 3.60/3.70, I discovered that "Find by Name" no longer appears as an option for POI searches. It's still there when searching Waypoints, but not for any of the POI searches. Can any of you confirm that they removed this from the latest firmwares? Because if they did, I'm really annoyed.

PQs get emailed. I can get fresh data without ever needing to visit the site, so it's not an inconvenience at all. The current number limits, however, are. And as has been stated before, along with the increase in caches over the years, also has come an increase in members, and thus an increase in funds available to upgrade those systems. And that's aside from suggestions like the 52 Complete State files, which would almost completely eliminate the PQ load on your SQL servers.

That's not quite it - after all, you said yourself that a butter knife makes a *poor* screwdriver. It's not that you can never make it work, but it's a lousy substitute under most circumstances. There is, however, zero loss of function if I take music from a purchased CD and put it on my computer or burn a mix CD. And in any case, while people might occasionally use a butter knife as a screwdriver, how many people *expect* a butter knife to work just as well as a screwdriver? Not many, if any. On the other hand, there are many people who want and expect music CDs to be rippable for legal reasons, and many people who want and expect downloaded caches to work with offline DB programs. And they both work perfectly with those alternate functions. That's the way things are nowadays - and just like the record companies, you adapt or you get left behind. No, it doesn't allow for everything I'm trying to do. Are you even reading the posts? Offline DB: You can change what you're looking for an UNLIMITED number of times per day. GC Website: You can change what you're looking for FIVE times per day. Offline DB: Works, regardless of whether or not GC.com is up, down, running slow, or having problems. GC Website: ONLY works if GC is up and running, not having problems, and is running at a minimally useable speed. Offline DB: Filtering results are shown immediately. GC Website: PQs are unpredictable as to when, or even IF they get sent out. You can minimize the time by creating a new PQ, instead of modifying an old one, but that still means you might wait 10 minutes per change, as opposed to TWO SECONDS. Offline DB: You can save as many filters as you want, to be used at any time. GC Website: You are limited to 40 PQs, and if you have the temerity to say it's not enough, you get piled on by a bunch of people who tell you that there must be something wrong with you if you're not doing things the way they do. Offline DB: Works, regardless of whether you have an internet connection or not. GC Website: ONLY works if you have internet access. Offline DB: Filtering puts zero load on GC's servers. GC Website: Filtering puts load on GC's servers - not only their web servers, but also their SQL servers. How can you think the two options are equal in functionality? GSAK offers more flexibility and more speed than GC's PQ creation. If you want to know exactly what it can handle, take a look at their website - or better yet, try downloading and learning to use it. Oh, and there's something else that's a very significant difference - the author of GSAK is very responsive and nice when it comes to user requests. GC on the other hand... I don't think I really need to finish that.

No. I still believe the ability to fine tune the filtering (at any time) is best served on the servers. All the data is stored there, it will not be changing there, it is the most current - so I should expect to be able to do it there. If I continue with the current scheme, I can change my mind about what I want 5 times per day everyday. And still get all the cache info I want for up to 500 caches in the 4.8 hours in between each change I make. <sigh> Let me try to put this in simpler terms for you: ------------------------------------------ If I did things My Way: "Hmm... I have the time to grab about six caches tomorrow. I think I'd like to grab a couple of micros." --- Run GSAK Filter --- "Okay, there's two of them that are promising. Hmm... I think I'd also like to grab a couple of traditionals." --- Run GSAK Filter --- "Way too many. Let's try ones that are at least a Difficulty of 3." --- Run GSAK Filter --- "There we go, I'll grab those. I think I'd also like to do a couple of Mystery caches." --- Run GSAK Filter --- "There's a lot here, but they're not the type that I like. Hmmm... I remember liking the ones by Avroair, let's try looking for those." --- Run GSAK Filter --- "Aha! Okay, now I've got my list!" ------------------------------------------ ------------------------------------------ If I did things Your Way: "Hmm... I have the time to grab about six caches tomorrow. I think I'd like to grab a couple of micros." --- Set PQ to grab only micros --- "Okay, there's two of them that are promising. Hmm... I think I'd also like to grab a couple of traditionals." "... shoot." ------------------------------------------ You talk about changing your mind up to 5 times a day. Well, I can change what I'm looking for 500 times a day (which isn't the same as changing my mind), and it doesn't require GC to be up and running, it doesn't require an internet connection, I don't have to be home, it puts zero load on GC's servers... If you still don't get it, I'm not sure I can make it any clearer for you. I never said that PQs were originally created for the purpose of offline databases. That doesn't change the fact that many people TODAY want to use them for that purpose. Record companies may have *intended* for music to be listened by playing the original CDs directly. That doesn't change the fact that many people TODAY want to be able to load it on their MP3 Players, or create a mix CD from the music that they've already bought, or put it on their computer so they can listen through iTunes/WinAmp/etc... The companies and artists that recognize this are well positioned to flourish through the upcoming years. The ones who insist on standing by their original intentions, crafted years ago before MP3 Players or consumer CD burners even existed, are being left in the dust. That's a much better analogy than your butter knife and screwdriver one. Because programs like GSAK *intend* for people to use those GPX files to populate them. Your analogy is about people using an item for something it's not suited for - which isn't the same as using an item for something it may not have been intended for, but works just fine all the same.

You still don't get it. I run different filters all the time, based on what I'm looking for. I might run 10 filters in 10 minutes, while I'm researching. I might be in the mood for one thing, one day, and be in the mood for something else, the next. I'm not going to run any filters to limit the root data set because once I do that, I shoot myself in the foot as I can no longer change the filter. Do you understand, now? First of all, there have been various statements by GC staff that contradict that. Responses to requests to raise the limits often have nothing to do with handheld GPS limits - but rather, state that GC staff feel that the limits are sufficient for people's needs in general. In light of those statements, my memory analogy works just fine. And while I have not done an extensive search on the subject, I don't recall any staff member yelling at people because they stated that they used GSAK or a similar program. So, while the current limits might have been *originally* intended to mesh with handheld GPS units, that is an archaic standard - not only because programs like GSAK, that didn't exist then, exist now - but also because many handheld units can store much more than 500 waypoints. As to what has changed, you forgot something - nowadays, many people want and expect the ability to download cache data for the purpose of creating offline databases. Whether GC is happy with that or not is irrelevant to the fact that many people are using programs like GSAK - and *like* it. Cell phone carriers have long said that they don't support their customers unlocking their phones. They can say it all they want - the CUSTOMERS have stated that it's *their* phones, they paid for it, and they'll do what they want with them. And you know what? The courts have agreed with them. So don't use a company's position on something as the be all and end all when it comes to a discussion of what customers need and want. It doesn't work.

Hilarious. Except that there's a serious response. If I only like 10 caches out of 1000, than the answer to how many more I need is "a lot". Some of you really need to realize that not everyone is as... indiscriminate... about which caches they go for.

I'm afraid you don't understand. What I was saying worked best for me was the ability to run as many filters as I needed *** through GSAK ***. In other words, having a complete set of data on hand and being able to switch what I'm looking for at a moment's notice - which is something that you can't do if you've filtered the data set itself.

As I've said before, I often don't log my caches, so the count is misleading. As to your other suggestion - I already limit the categories of caches that my PQs pull. What's left is still a large set, but I choose from all the remaining categories and difficulty/terrain levels, so I can't limit it any further.

Ah, that was a mistake on my part, for which I apologize. My referencing 120 PQs per week was a tripling of the current limit of 40 PQs - but that's not a weekly limit, it's the total number of stored PQs period. What I should have said was that there should no longer be a limit on stored PQs. If they're already limiting the number of PQs that can be run, there's no need to limit the number that you can create to choose from. Well, the buffet analog worked for what I was pointing out - but it doesn't work so well here because there's no need for people to keep track of the total food on the table. A slightly better analogy here is computer memory. A few years ago, the average consumer PC had around 512 MB of RAM. That was fine at the time, but nowadays, there are software apps are showing 1-2 GB *minimum* requirements. Currently, people's needs and wants have caused the consumer PC to average around 2 GB of RAM. And the cost for 2 GB of RAM today is approximately what 512 MB cost years ago. The price is about equal, but you're getting more because current apps use more memory, and also because people are doing more with their PCs. What GC is doing is the equivalent of saying that 512 MB was sufficient years ago, so they're only going to offer 512 MB now. Sorry, but cache density has grown - and what they offer should grow to match it.

I understand that method just fine, and I use it myself. I think I just misunderstood what you were saying by bringing it up. For me, I use it to eliminate overlap, and it *still* takes 25 PQs to get a 100 mile radius.

See, you're making a few assumptions here - and I'm guessing that it's based on how you cache. A lot of people seem to cache by simply going through a list of what's nearby. These are typically going to be the folks that make comments like "I've found 1000 of the 2100 caches around me - therefore I still have 1100 to go. Plenty for me!" And if they enjoy doing that - fantastic, I'm glad that they can be happy with that. Personally, I can't stomach finding eight hundred lamppost/guardrail/I-had-30-seconds-while-taking-a-pee-so-I-thought-I'd-toss-a-cache-over-my-shoulder caches (and this is only one category, not all). In other words, most of the caches in a given area don't do it for me. So for a person who just goes down the list, you can say they get 300 caches per penny. But that doesn't hold true for me, or anyone else who's selective about their caches. I remember that someone else once suggested that they should just have a regularly updated list of 52 files, representing all caches organized by state. You have to admit, if they did that, it would significantly cut down on the load on their SQL Servers.

I think you need to go back and read a bit more closely. I didn't make that statement simply because an alternate suggestion was made. I made that statement because you were implying that I was being unreasonable in not caching the way you and many others do. I have thought about it extensively. And the maximum flexibility I can get to maximize my enjoyment comes from being able to execute as many or as complex filters as I need through GSAK - which occurs instantaneously, does not require an internet connection, and is not dependant on whether GC.com is running or not. You're making many assumptions about how I cache - most, if not all of them, completely wrong. 1. Sometimes, I take several days to plan out which caches I want to attempt. This involves many hours of searching for what I want and where I want it. 2. I don't always know I'm going to cache, or even have the opportunity to, until it happens. This has nothing to do with me being a person "who can't decide where to cache until the last minute". 3. It takes so many PQs to get a complete listing given the current limitations, that given the useless restriction of 40 *stored* PQs, I don't always have slots free to add new ones. And here you go again, when you reference people "willing to do this with only the last 5 logs instead of the last 50 logs". Again, you're implying that my way of caching is unreasonable, and everyone else is doing it "the right way". I'm sorry, but it's not your place to decide how a person should or should not cache. If you want to do it with 5 logs - more power to you. If someone wants to do it with 50 logs, it's none of your business, and it's not your place to judge. I am not, nor have I ever, tried to tell everyone else that they're caching with too little research and too little data. They cache how they want to cache, and if it makes them happy - that's what counts. But a lot of you can't seem to reciprocate with that same type of open mindedness - and THAT'S where I take issue. I appreciate the suggestion - but it's not an acceptable solution because: 1. It requires cell phone coverage - many areas do not have coverage, or do not have reliable coverage. 2. It requires a GPS enabled phone, which not everyone has (I certainly don't). 3. It assumes that GC's servers are up and running, running well, and without errors - personally, I'd rather buy a lottery ticket than gamble on that one.

The placement date has nothing to do with when a cache may change, be stolen, be submerged, or anything else - which is why I update all caches, not just the newer ones. So it doesn't really do much for efficiency, as far as that's concerned. That being said, if you think you're getting good value for your money - I'm happy for you, honestly. I just happen to feel differently, that's all.

And I don't begrudge you that at all. But here's another way of looking at it... In 2002, 5 PQs per day at 500 caches each gave you all the caches in what radius? In 2008, 5 PQs per day at 500 caches each NOW gives you all the caches in what radius? And how many more members are there paying $30 per year in 2008 than there was in 2002? And yet, you're still getting only 5 PQs per day at only 500 caches each. To me, that's not cool at all. But that's me.

I'm not surprised at any of these things, nor did I ever say that I was. The large number of people who reply to my posts on this subject whenever it comes up seem to make it pretty clear that the way I cache *is* different from the way a lot of people do it. So forgive me if their prior posts have already rebutted you. You are sadly mistaken as to what is going on, I'm afraid. I'm not trying to convince anyone that there's anything wrong with the way they cache (many of them cannot say the same). Nor am I trying to convince anyone that my way of caching is superior to anyone else's (also, many of them cannot say the same). The primary point I've been trying to make is that my way of caching is JUST AS VALID as anyone else's - and it is neither their place, nor yours, to tell me otherwise. If you're okay will all of those "maybe" compromises you list above, that is 100 percent your prerogative. But don't tell me what I should be happy with. I will remind you that I was not the one who started this thread regarding the PQ limitations. I am simply *another* person who believes that the PQ limitations are archaic and too constricting. If you're completely happy with them, than that's wonderful - honestly. But don't get in the way of people for whom it doesn't work.

And AT&T obviously feels it's okay to give out their customer's info and allow the government to wiretap them without a warrant. I'm sorry, but just because the company wants to do something doesn't automatically make it right - and it doesn't mean the users/customers don't have every right to say that they have opinions to the contrary about what services the company provides and the method in which they provide it.

Forgive me, but I'm not sure I understand where the 180,000 is coming from. Right now, just to get a 100 mile radius, I need 25 PQs, which amounts to 12,500 caches. This doesn't take into account PQs to cover other areas which I may travel to. My recommendation to triple the current limits was largely a matter of addressing the exponential growth of geocaching over the years. To clarify: Cache Limit per PQ: The current limit of 500 caches is ludicrously low, given high density areas. Maintaining 25 PQs for a simple 100 mile radius is a bit much, don't you think? If part of the reasoning has to do with what older GPS's are capable of storing - well, then the individuals who have this consideration can simply set the number of results to 500. Meanwhile, users who don't have that limitation shouldn't have to be bound by it. PQ Limit per Day: 5 PQs per day is far too little, considering what is stated in the paragraph above. Now, if the Cache Limit per PQ is increased significantly, this limitation doesn't have to increase as much - so they're connected to some degree. However, people who are traveling or who routinely travel a lot may have the need for many smaller PQs, and they would be constrained by a tight limit here. PQ Limit Total: This limitation is absolutely ludicrous in that it even exists in the first place. If you're already limiting the number of PQs that can be run, what difference does it make how many a user stores in his account to choose from? It takes up a negligible amount of space and zero load if they're not running. As for the need for greater numbers - other than the reasons I already gave in earlier posts, an additional fact to consider is that programs like GSAK offer significantly more flexibility and complexity in how caches can be filtered and searched - not to mention the fact that doing it offline is much faster and puts zero load on GC's servers. For example, if a user was in the mood to search for caches that can be driven up to and retrieved without getting out of the car, for days of truly horrible weather, that would require a complicated full text search and would still come up with pittiably few results. To come up with any reasonable number of them, it would indeed require a large pool of caches to search from in the first place. Again, I'm not sure where 180,000 is coming from - but I remind you that having the option doesn't mean that everyone is going to use it. Are you telling me that you wolf down everything in sight when you're at a buffet? Of course, not. I'm just saying that the option should be there. If I build a system for someone, I'm not just taking into account what they need to do, but what they *might* need to do. It's the same thing here. You're also making the mistake of taking the suggested limits cumulatively, instead of considering the smaller packet-oriented way they might be actually used. For example, let's say, using my 100 mile radius (at the moment - 12,500 caches), I haven't cached for a month. If I want to update my DB so I have the option the next day, with 1500 caches per PQ and let's say, a limit of 10 PQs per day, I can update in one day - which means I can update on Friday and go caching on Saturday. This is reasonable. However, with the current limits of 500 caches per PQ and 5 PQs per day, it would take me five days to update - which means that if I'm thinking on Tuesday that I might like to cache that weekend, it's already too late to get a full update. This is closer to how the limits are likely to be used, rather than someone maxing out every single number possible all the time. It's not just the number of caches that's grown over the years, it's the number of members as well. This increase in income is what pays for the system upgrades that would allow for the additional load that comes with the greater numbers.

Just because a task is difficult doesn't mean it's not worth pursuing.

900,000 PQs per year is completely inaccurate. The current limits call for a maximum of 5 PQs per day, which amounts to 35 PQs per week - which yields a maximum of 1820 PQs per year. This is not overkill at all - it completely depends on how people cache. That being said, I think I have to agree with you on your suggested tactics. Unfortunately, many posts which go against the common thinking here tend to be met with anger, derision, and/or scorn - as opposed to thoughtfullness and consideration, so an attempt on those lines is unlikely to get very far.

EDIT - GC site burp - Duplicate Post - Ignore.