Jump to content

Geocaching.com site update April 17th 2013


Recommended Posts

Read the last update's Release Notes

 

Release Notes

 

The Geocaching team has been working like crazy to roll out updates and enhancements that will make your Geocaching adventures easier, faster and more awesome. Here are a few of the highlights:

 

  • New and improved Geocaching Weekly Mailer, coming soon — Recent geocaches, nearby events and Mega-Event calendars will be easier to read. We'll also start using linked images instead of embedded images for faster downloading.

  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

 

Link to comment

  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

 

This is a joke - right?

 

You are taking away some functionality and then sell it as an improvement?

 

The search facility is limited enough as it is without this new restriction. What is the big performance problem here? Is Groundspeak using some toy-database software to handle all the data, or is it simply the aged and ever expanded database scheme which makes effective searching impossible? A 'real' database should not have any problems looking for a string in some 2 million cache titles...

Link to comment

  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

 

This is a joke - right?

 

You are taking away some functionality and then sell it as an improvement?

 

The search facility is limited enough as it is without this new restriction. What is the big performance problem here? Is Groundspeak using some toy-database software to handle all the data, or is it simply the aged and ever expanded database scheme which makes effective searching impossible? A 'real' database should not have any problems looking for a string in some 2 million cache titles...

 

Well they have to do something. Right now it's midweek, mid day where I am, and I give up trying to enter anymore logs right now. The response time has slowed to the point where it isn't worth it to continue any more right now. If I can only have one or the other, I would rather be able to write logs. And perhaps we can find a way to make a worthless TFTC log take only milliseconds as well. I'm sure they will be able to call that an enhancement as well, all the while continuing to maintain a strait face.

Link to comment

  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

 

This is a joke - right?

 

You are taking away some functionality and then sell it as an improvement?

 

The search facility is limited enough as it is without this new restriction. What is the big performance problem here? Is Groundspeak using some toy-database software to handle all the data, or is it simply the aged and ever expanded database scheme which makes effective searching impossible? A 'real' database should not have any problems looking for a string in some 2 million cache titles...

 

Its open source....you get what you pay for.

Link to comment

The Geocaching team has been working like crazy to roll out updates and enhancements that will make your Geocaching adventures easier, faster and more awesome. Here are a few of the highlights:

  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

 

 

NICE UPDATE!

Since we can't find caches unless we know the beginning of the cache name it should really help on performance.

The fact that we can't find caches from the map above zoom level 11 should also help bigtime. (http://forums.Groundspeak.com/GC/index.php?showtopic=309949)

Good work!

 

--

OhKay

Link to comment

The Geocaching team has been working like crazy to roll out updates and enhancements that will make your Geocaching adventures easier, faster and more awesome. Here are a few of the highlights:

  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

 

 

NICE UPDATE!

Since we can't find caches unless we know the beginning of the cache name it should really help on performance.

The fact that we can't find caches from the map above zoom level 11 should also help bigtime. (http://forums.Groundspeak.com/GC/index.php?showtopic=309949)

Good work!

 

--

OhKay

 

I have to agree that this new "Starts with" search is awful, totally useless. We need the "Keyword" search back!! I went in to the Advanced Search options and there is still a "Keyword" search option but when I tried to use it it seems to be a "Starts With" search. I am trying to search for Nifty Fifty cahes, I know they exist but they do not all start with "Nifty Fifty" so I am out of luck. It may be great that the search is Uber fast but if it does not yield the desired results it is worthless.

 

GO BACK TO "KEYWORD" SEARCH

Link to comment
  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

 

This has got to be a bad joke!

Link to comment

  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

 

This is a joke - right?

 

You are taking away some functionality and then sell it as an improvement?

 

The search facility is limited enough as it is without this new restriction. What is the big performance problem here? Is Groundspeak using some toy-database software to handle all the data, or is it simply the aged and ever expanded database scheme which makes effective searching impossible? A 'real' database should not have any problems looking for a string in some 2 million cache titles...

 

Names are not even reliable. You should be searching by GC codes. Remember the GC codes and you're golden. I keep records of them.

Link to comment

Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

Great, it's faster than my internet connection, but unusable.

 

Another thing: There is really many maps, more than monitor size of my netbook. Some maps do not display Europe, one is totally useless (Watercolor). How can I get this maps out from the menu?

g44tdre63gokqdcbm0bx.png

I know, I can't...

Link to comment

Thanks for the "improvement" in the maps. Thanks for the new useless maps (the world also continues behind the USA borders!). And thanks also for the new Javascript Errors in the maps! Do you have some programmer, or is only high-school student with free time? Some testing? Never heard about?

Link to comment
  • Performance enhancements We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much fasterwe're talking milliseconds.

 

This has got to be a bad joke!

 

That's really great: taking an almost useless feature and turning it into a completely useless feature and then talking about improvements.

I'm really wondering what happened to all those database specialists in Seattle - either none of them works for Groundspeak or no one asks them how to create a keyword search that actually returns a list of caches that you really want to go searching for.

 

I'll give you an example: I really love doing challenge caches and I'd really like to know which active challenge caches exist in the area I normally cache in. That's Northrhine-Westfalia in Germany and the Netherlands. Currently it's simply not possible to get this information out of the database in an easy way.

 

If I use the (old) keyword search I'd enter "challenge" because every challenge cache is supposed to have the word challenge in its name. What do I get: a really long list of challenge caches from all over world of which about 90% for me are absolutely not relevant because I won't go searching in California, Ontario or New Zealand any time soon.

What I would like to see is only the 10% caches from my area. So what would help me find stuff would be a combination of filters (like the ones you can define for the pocket queries) plus the possibility to add a keyword (maybe with wildcards).

For the database search that means instead of doing a text search on over 2 million recordsets (I assume you filter out the archived caches beforehand) you'd filter first for search criteria (e.g. Germany) and then perform the text search only on the filtered number of caches. For this example this means text search on about 250.000 instead of 2 million recordsets.

So you'd actually have a win-win-situation: you provide us with a useful feature and have less search load on the database.

 

Just my 2 cents

Atti

Edited by Atti
Link to comment

The Map Preview of the Pocket Queries ist totaly buggy - it shows no Caches at all. No list of filtered caches on the left but only a list of my Pocket queries. If I click one, nothing happens. When I click on the headline "Pocket Queries", it shows ALL Caches in the area and not the ones filtered by the query.

Please repair as soon as possible!!! (And give back Google Maps instead of watercolor and forest transport)

 

JavaScript Error when trying to call a PQ from the map:

 

Timestamp: 18.04.2013 10:53:05
Error: TypeError: MapSettings.MapLayers.PocketQuery.addGeoJSON is not a function
Source File: http://www.geocaching.com/ScriptResource.axd?d=xxxxxxxxxxxxxxxxxxxxxxxxxxx
Line: 4187

Edited by austriaka
Link to comment
  • New and improved Geocaching Weekly Mailer, coming soon — Recent geocaches, nearby events and Mega-Event calendars will be easier to read. We'll also start using linked images instead of embedded images for faster downloading.

I hope this includes an improved, personalized distance filter. If so, thanks!

 

Nice, but I'll stick to my own pictures.

 

  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

I'm sure this will be faster, but can you make the old keyword search available as an extra parameter in the pocket queries? It certainly could be an extra reason to become or stay a premium member...

Link to comment

There was a thread started a couple days ago about the "improved" search system. All kinds of tips on how to use Google search to find what you're looking for. It will certainly speed up GC's search engine if everyone is using Google instead.

 

Look Here for discussion of workarounds to the performance enhanced geocache search if you are not happy with the results you are getting in milliseconds.

Edited by cheech gang
Link to comment

It's really sad that you degraded your search feature and are trying to market it as an improvement. The only good thing that I see coming from this is perhaps a good Sunday Dilbert panel. When Marketing and Engineering merge into the same mindset, we're all doomed.

 

The spin is like an old joke I once heard. Bad news, I accidentally drove my car off a cliff. What's the good news? It got 200 miles to the gallon on the way down.

Link to comment

I have no skill set that allows me to judge otherwise, so I must take Moun10Bike on his word that the degradation of the name search function has created enhanced performance somewhere else in the system. It is obviously not an enhancement to the search function itself.

Edited by cheech gang
Link to comment

OMG, people people, please.... harsh harsh harsh comments I read. A bit embarishing to read.

 

Think of this:

The developers at Groundspeak know best what to do. They are the only ones that know the system, what problems they are facing, what needs to be done. It is embarishing to read that people who have no knowledge about the system judge in such a hard manner.

 

As a user I have difficulty reading the comments. Can you imagine how the developpers at groundsepak would feel. I wouldn't blame them if they wouldn't read it at all anymore.

 

- Robert

Link to comment

OMG, people people, please.... harsh harsh harsh comments I read. A bit embarishing to read.

 

Think of this:

The developers at Groundspeak know best what to do. They are the only ones that know the system, what problems they are facing, what needs to be done. It is embarishing to read that people who have no knowledge about the system judge in such a hard manner.

 

As a user I have difficulty reading the comments. Can you imagine how the developpers at groundsepak would feel. I wouldn't blame them if they wouldn't read it at all anymore.

 

- Robert

 

Well, I get your point. But as a developer, you have to think what a custumor wants, and needs. Such as this keyword search(I havn't used it, but I see it's somewhat usefull for those who search for a spesific cache, or theme.) You have heard about some essence of the cachedescription or remember part of the name of the cache. Then it usefull to search for these keywords.

 

This new search is totaly useless if you don't remember the exact start of the name of the cache. I get it's much faster to search for the begining of the cachename then keywords, but still, it's totally useless as a searchengine. How would google been now, if you could only search for the the title of text to yield results, and no keywords?

 

I also gets the developers wants that searching would go much faster, but there is so much other things to look into why keyword searching is slow, and much other ways to solve it. Is the database optimized, maybe there is someway to cache the results and so on and so on.

 

At the end, we are the custumors of Groundspeak, many of us pay the salary to the developers (we buy premium), and I think we are entitled to get a bit angry when they choose the "easy way out".

Edited by laffa
Link to comment

The developers at Groundspeak know best what to do. They are the only ones that know the system, what problems they are facing, what needs to be done.

That the developers are the ones making the decisions is precisely the problem. Someone who knows what the users want and where the site should be going (ie. Jeremy et al.) is the one who should be making design decisions, and then tasking the developers with building the system to accomplish that vision. Letting the patients run the asylum just won't work, as evidenced by some of the recent questionable decisions on this site.

 

This site is going off the rails, and someone needs to step in and get it back on track.

Link to comment

None of us has any idea what constraints the developer was facing, so it's really remarkably rude to assume that the decision was boneheaded.

 

Feel free to complain about the change, but, please, stop insulting the poor people slinging bits. If this really was a serious error in judgement, that message will get through without you cramming their faces in it.

Link to comment

What got me upset when I read the announcement was the fact that someone is trying hard to pass this off as an enhancement and as something for us to get excited about. It's a major step backward in terms of search capability, and everyone knows it, the developers, the marketing people, and we humble users.

 

The change might well be necessary to keep the Web site from bogging down, but I wish they'd simply said something to that effect instead of insulting our intelligence and trying to make us believe this is something we've all been waiting for.

 

--Larry

Link to comment
What got me upset when I read the announcement was the fact that someone is trying hard to pass this off as an enhancement and as something for us to get excited about. ...

 

The change might well be necessary to keep the Web site from bogging down, but I wish they'd simply said something to that effect instead of insulting our intelligence and trying to make us believe this is something we've all been waiting for.

Looking back at the Release Notes at the top of this thread, I see the search change labeled as a "Performance enhancement" which is exactly what you were just asking for. They never claimed it was a better search, just a faster search.

Link to comment
What got me upset when I read the announcement was the fact that someone is trying hard to pass this off as an enhancement and as something for us to get excited about. ...

 

The change might well be necessary to keep the Web site from bogging down, but I wish they'd simply said something to that effect instead of insulting our intelligence and trying to make us believe this is something we've all been waiting for.

Looking back at the Release Notes at the top of this thread, I see the search change labeled as a "Performance enhancement" which is exactly what you were just asking for. They never claimed it was a better search, just a faster search.

Performance is more than just "speed". A slower search that yields better results could be said to perform better. I never noticed speed problems with the old search anyway (that couldn't be blamed on my internet connection).

Link to comment

The performance improvement was primarily a reduction of database load. Before this change, we were routinely hitting max CPU load on the weekends, causing many site functions to fail and leading to overall slowness. Since this change was implemented, we have been maxing out around 30% load.

 

You might think it odd that such a simple search function had such an effect on performance, and we do too - to the point that we think this feature was in some way being abused (intentionally or unintentionally) by some third party out there. In any case, we had to make the change in order to ensure that the site continues to operate.

 

We know we need better search tools, and see this as a temporary band-aid until we can implement them.

Link to comment

The performance improvement was primarily a reduction of database load. Before this change, we were routinely hitting max CPU load on the weekends, causing many site functions to fail and leading to overall slowness. Since this change was implemented, we have been maxing out around 30% load.

 

You might think it odd that such a simple search function had such an effect on performance, and we do too...

 

I am not the least bit surprised that the CPU load has dropped so dramatically - hardly anyone will be using the search now because it is seriously next to useless.

 

I do have to wonder whether there is a better way of indexing cache names, or keywords from cache names, such that a keyword search can be more efficient. It just needs to be tailored to the problem you have - lots of queries against a relatively stable set of records. A little bit of indexing time when a cache page is created or updated could go a long way to making queries run faster over the long term.

 

I would hope this was all thought through by the team, but the result - turning a useful query into something that's just not worth bothering with at all, and utterly ineffective for the customer base in general - suggests otherwise. :(

Edited by funkymunkyzone
Link to comment

None of us has any idea what constraints the developer was facing, so it's really remarkably rude to assume that the decision was boneheaded.

 

Feel free to complain about the change, but, please, stop insulting the poor people slinging bits. If this really was a serious error in judgement, that message will get through without you cramming their faces in it.

 

My only issue is with trying to sell this to us as an upgrade that we will benefit from.

Link to comment

The performance improvement was primarily a reduction of database load. Before this change, we were routinely hitting max CPU load on the weekends, causing many site functions to fail and leading to overall slowness. Since this change was implemented, we have been maxing out around 30% load.

 

You might think it odd that such a simple search function had such an effect on performance, and we do too - to the point that we think this feature was in some way being abused (intentionally or unintentionally) by some third party out there. In any case, we had to make the change in order to ensure that the site continues to operate.

 

We know we need better search tools, and see this as a temporary band-aid until we can implement them.

 

I can appreciate this response. I don't want to sound too critical, but I think a bit of transparency has been lost over the years. While some will always complain, I think that starting with just the facts and saying this is what we must do, and it is a temporary situation is so much better then trying to sell it as an enhancement.

Link to comment

The performance improvement was primarily a reduction of database load. Before this change, we were routinely hitting max CPU load on the weekends, causing many site functions to fail and leading to overall slowness. Since this change was implemented, we have been maxing out around 30% load.

 

You might think it odd that such a simple search function had such an effect on performance, and we do too - to the point that we think this feature was in some way being abused (intentionally or unintentionally) by some third party out there. In any case, we had to make the change in order to ensure that the site continues to operate.

 

We know we need better search tools, and see this as a temporary band-aid until we can implement them.

 

Ahhh, and you are also aware of the fact, that Geocachers in an EURO-Country are abused (intentionelly, I guess) to pay more for a premium membership than others. And don't explain this with taxes and bank charges!

 

A US resident pays 29,99$ + VAT (9.5% = around 3$, right), in sum 33$. In Germany, or any other country within the EURO zone, people have to pay around 29,99€ = 39,14$ (1 EUR ~ 1,31 USD).

Link to comment

The performance improvement was primarily a reduction of database load. Before this change, we were routinely hitting max CPU load on the weekends, causing many site functions to fail and leading to overall slowness. Since this change was implemented, we have been maxing out around 30% load.

 

You might think it odd that such a simple search function had such an effect on performance, and we do too - to the point that we think this feature was in some way being abused (intentionally or unintentionally) by some third party out there. In any case, we had to make the change in order to ensure that the site continues to operate.

 

We know we need better search tools, and see this as a temporary band-aid until we can implement them.

 

Ahhh, and you are also aware of the fact, that Geocachers in an EURO-Country are abused (intentionelly, I guess) to pay more for a premium membership than others. And don't explain this with taxes and bank charges!

 

A US resident pays 29,99$ + VAT (9.5% = around 3$, right), in sum 33$. In Germany, or any other country within the EURO zone, people have to pay around 29,99€ = 39,14$ (1 EUR ~ 1,31 USD).

 

Off topic, but well spotted. Last year I paid my premium membership in USD, this year I will have to pay it in GBP. £24.99 is an exchange rate of 1.2 compared to a realistic rate of at least 1.5. Could someone explain what I get for my extra £5?

 

Oh, and back on topic, I completely agree with all the comments about the cache name searches. Just this morning I heard about a series and tried to find it, but because the CO had used an abbreviation at the start I was unable to find it. This is a real backwards step.

Link to comment

Based on the negative tone of some posts above, it seems to me like many here make this hobby MUCH too difficult and take it MUCH too seriously.

 

If you want to do a search, stick to the basics and you will be fine (you know - putting in the zipcode, then using the "map it" feauture.) I have been geocaching for awhile now and NEVER had to search for a cache by name - NOT ONCE!

 

If you don't like how Groundspeak handles things - cancel your account and use another geocaching sight. OR - you could always revert back to traditional letterboxing.

 

I for one am appreciative of all the behind the scenes work the Groundspeak folks do for the sake of MY recreation. Thanks all!

Link to comment

 

If you want to do a search, stick to the basics and you will be fine (you know - putting in the zipcode, then using the "map it" feauture.) I have been geocaching for awhile now and NEVER had to search for a cache by name - NOT ONCE!

 

 

Your find rate averages about 60 caches per year so I can understand that you have little need for the search function. You also live in an area sparsely populated with caches. I have over 1000 caches within 5.5 miles of my residence in the San Diego area. I don't mean to disparage your caching experience in any way, I cite the numbers only to illustrate your activity on the system is very light. I don't have the ability to remember exact names of many thousands of caches, nor the desire to sort through densely populated maps to locate a cache I'm trying to find.

 

There are many, many reasons to do a cache search by name. One is a cache that is related to one that you find and is mentioned in the description. Perhaps one would like to read a cache that is mentioned in the forums or by a friend; often such references are not an exact quote of the title. Or you may want to find all of a series that is not bookmarked. Most frequently for me is searching for a cache I was reading about in the past. The list is virtually endless.

 

Lastly if a tool is provided, it should be functional. Because I don't use a particular tool doesn't mean others should use the system the way I do. I enjoy the hobby and want the time I have to spend at the computer to be minimal so I have more time to spend actually looking out doors.

Edited by GeoTrekker26
Link to comment

The performance improvement was primarily a reduction of database load. Before this change, we were routinely hitting max CPU load on the weekends, causing many site functions to fail and leading to overall slowness. Since this change was implemented, we have been maxing out around 30% load.

 

You might think it odd that such a simple search function had such an effect on performance, and we do too - to the point that we think this feature was in some way being abused (intentionally or unintentionally) by some third party out there. In any case, we had to make the change in order to ensure that the site continues to operate.

 

We know we need better search tools, and see this as a temporary band-aid until we can implement them.

 

I can appreciate this response. I don't want to sound too critical, but I think a bit of transparency has been lost over the years. While some will always complain, I think that starting with just the facts and saying this is what we must do, and it is a temporary situation is so much better then trying to sell it as an enhancement.

 

This

Link to comment

 

I'm really wondering what happened to all those database specialists in Seattle - either none of them works for Groundspeak or no one asks them how to create a keyword search that actually returns a list of caches that you really want to go searching for.

 

I'll give you an example: I really love doing challenge caches and I'd really like to know which active challenge caches exist in the area I normally cache in. That's Northrhine-Westfalia in Germany and the Netherlands. Currently it's simply not possible to get this information out of the database in an easy way.

 

If I use the (old) keyword search I'd enter "challenge" because every challenge cache is supposed to have the word challenge in its name. What do I get: a really long list of challenge caches from all over world of which about 90% for me are absolutely not relevant because I won't go searching in California, Ontario or New Zealand any time soon.

What I would like to see is only the 10% caches from my area. So what would help me find stuff would be a combination of filters (like the ones you can define for the pocket queries) plus the possibility to add a keyword (maybe with wildcards).

For the database search that means instead of doing a text search on over 2 million recordsets (I assume you filter out the archived caches beforehand) you'd filter first for search criteria (e.g. Germany) and then perform the text search only on the filtered number of caches. For this example this means text search on about 250.000 instead of 2 million recordsets.

So you'd actually have a win-win-situation: you provide us with a useful feature and have less search load on the database.

 

I really like the idea of this type of search, and would like to see a similar set-up for notifications. If I could set up a location, choose the log types I want, and choose the cache types all in one notification it would be quite convenient. Currently you have to set up for each type of cache separately and it's a fairly time-consuming task.

Link to comment

Off topic, but well spotted. Last year I paid my premium membership in USD, this year I will have to pay it in GBP. £24.99 is an exchange rate of 1.2 compared to a realistic rate of at least 1.5. Could someone explain what I get for my extra £5?

 

Oh, and back on topic, I completely agree with all the comments about the cache name searches. Just this morning I heard about a series and tried to find it, but because the CO had used an abbreviation at the start I was unable to find it. This is a real backwards step.

 

This reminds me of:

On an office wall here at HQ is a sign that reads, “Let’s make better mistakes tomorrow.”

I guess they read the sign...

 

Currently it is almost impossible to find a challenge cache by just searching for 'challenge' and the VAT charge is very badly communicated.

Edited by Kalkendotters
Link to comment

  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

 

This is a joke - right?

 

You are taking away some functionality and then sell it as an improvement?

 

The search facility is limited enough as it is without this new restriction. What is the big performance problem here? Is Groundspeak using some toy-database software to handle all the data, or is it simply the aged and ever expanded database scheme which makes effective searching impossible? A 'real' database should not have any problems looking for a string in some 2 million cache titles...

 

Fast is great.. no cache found is useless.

Link to comment

  • Performance enhancements — We changed the way our search by geocache name function works to provide a huge relief to our database load. Now keyword searches only search the first term in a geocache's name, but is much faster—we're talking milliseconds.

 

This is a joke - right?

 

You are taking away some functionality and then sell it as an improvement?

 

The search facility is limited enough as it is without this new restriction. What is the big performance problem here? Is Groundspeak using some toy-database software to handle all the data, or is it simply the aged and ever expanded database scheme which makes effective searching impossible? A 'real' database should not have any problems looking for a string in some 2 million cache titles...

 

Its open source....you get what you pay for.

well, i think you're a bit unfair. you mean expensive proprietary code is better? well, what would it cost ya?

Link to comment

The performance improvement was primarily a reduction of database load. Before this change, we were routinely hitting max CPU load on the weekends, causing many site functions to fail and leading to overall slowness. Since this change was implemented, we have been maxing out around 30% load.

 

You might think it odd that such a simple search function had such an effect on performance, and we do too - to the point that we think this feature was in some way being abused (intentionally or unintentionally) by some third party out there. In any case, we had to make the change in order to ensure that the site continues to operate.

 

We know we need better search tools, and see this as a temporary band-aid until we can implement them.

 

I trust on you and I hope you find something soon. It's obvious that the search load is reduced as a lot of people are not searching anymore (I know at least 5 including myself). In former times it was possible to search for a city name as a first approach to the cache of that town. Today this is not possible anymore. In former times it was possible to search for the real keywords of a cache name as "around the world" or something like that. Today I have to know if the names starts with "The" or "A cache..." or whatever else. For me the search should enable us to find something. If somebody tells "use the GC code" I just say: In that case there is no need to search, I already know it.

 

Please work on the search quickly and give us back what we had before - or even a better version with wild cards and maybe with regular expressions.

 

... and just to make things complete: Why is the "search by name" not the first search option? At least from my experience (not only my personal experience) the search by name is the most used option compared to search by adress (I've never figured out how to use this) or seek by coordinates. For me the "other search options" are the most important options - and each time I want to use them I have to scroll down to reach them :-(

Link to comment

 

{snip}

 

We know we need better search tools, and see this as a temporary band-aid until we can implement them.

 

 

I know Moun10bike would not knowingly jerk us around. But I also know GC.com's track record. How long is it now they have been promising geocaching.com 2.0, a new gpx structure, a new and improved PQ, and who-knows-what-else? And now a suggestion of a new and improved search? Believe me, Moun10bike, this is certainly nothing personal, but I won't be holding my breath.

Link to comment

Not that i'd ever use it, but the Area Code search is also flawed. I live in an area that has two different area codes, yet when I enter one of them I get one list and if I enter the other I get a different list.

Edited by edscott
Link to comment

Not that i'd ever use it, but the Area Code search is also flawed.

I was going to poke fun at your post, because I thought you meant "ZIP code", but then I checked and realized there really is an area code search! That doesn't seem particularly useful at all. As a test, I looked up North Dakota and found that they only have one area code (701). Doing a search by that area code gives a resulting centerpoint of N 46° 25.086 W 096° 42.714. These coordinates are half a mile from the Minnesota border, way down in the southeast corner of the state. If area codes are going to be used as a search option, they should at least use the center of the area the code covers, not some random point way off on the edge. I also looked up Montana, Idaho, Wyoming, and South Dakota, because they each have a single area code covering the respective state. All the centerpoints are in similarly random and useless locations. I know the problem likely lies with the geocoding source, but the one that's currently being used leaves a lot to be desired.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...