BonnerGuido

I think that the current D/Ts are correct enough most of the time. But I would love to see an extension of this idea: free tagging. You would be able to add something like "scenic view" or "near castle" or "cool container" to any cache. I would suggest adding a value from 1 to 5 to every tag/vote, with "scenic view":5 meaning very scenic view and "scenic view":1 meaning no nice view at all. This would make D/T a special case and easy to include. This could be done as a broswer extension like (my) GCVote, which allows you to rate the quality of caches. I even thought about adding tagging to GCVote, but I think that it should be a seperate extension. And I would not have time to implement it anyway.

Skywalker90 hat einen sehr gut laufenden Prototypen fertig, den ich hoffentlich bald offiziell übernehmen kann. Dazu gibt es einen Thread mit Downloads im Grünen Forum. Den Link spare ich mir mal, weil Groundspeak es wohl nicht gerne sieht, wenn auf Konkurrenz verlinkt wird.

Oh, that's an interesting idea and would be very easy to fix. GCVote is not about making money and I would remove the button if that really helps. It's just nice to have other people pay for most of the server costs.

I cannot find any existing thread about this, even though I know of several other German geocachers with the same problem. All mails from geocaching.com seem to arrive several hours after they were sent. Notifications and personal messages carry a timestamp of 8 to 14 hours before they arrive in my mailbox. I have the impression that they spend this time in some queue, but maybe the server's time is simply off. All other mails arrive on time, so I don't think that my email provider is at fault. Does anybody experience anything similar?

You may find what you want here: GCVote

Well, neither of that is true, as far as I can tell. Pleople DO find the ugly caches, but they do not rate them very high. I guess that they are like me and like any cache more than no cache at all, so they grab the easy cache along the way no matter how ugly it may be. The number of found-logs is a bad indicator of the quality of a cache. If you look at Caches in Germany, where GCVote is well used, you will find that the ratings make sense most of the time. I read a lot about the good reasons why a simple rating system cannot work and actually wrote GCVote to prove them wrong. I'm sure that there are geocachers with very specific tastes and caches that get dubious ratings, but for most users most of the ratings seem to be very helpful.

I think that I'll add an option for this in the next version of GCVote. It'll disable GCVote on all pages that contain an unlimited number of caches. I'll try to include a button to manually load and display the ratings on those pages. Would that help?

Did you install the compatibility script? I did a quick check with my installation and it seemed to work, more or less. IE7Pro did not automatically install gcvote.ieuser.js, but everything else looked fine and GCVote worked, too.

I don't have time to boot Windows and check this, but from a quick glance at the source, this should only happen if IE7Pro is not installed. But I may be wrong.

I don't have time to boot Windows and check this, but from a quick glance at the source, this should only happen if IE7Pro is not installed. But I may be wrong.

I heard reports like that before, but I'm not really about the cause. I guess that you have a very large number of caches on your list of recently found caches? Since the browser should not freeze while waiting for the GCVote server to reply, I expect that the Javascript engine is too slow. The good news is that all browsers are improving their Javascript performance. I may add an option to GCVote, so nobody has to edit the configuration by hand. But for that I need to know which pages are the slowest.

That's a very good argument that bugged me a few years ago. To prove that a cache rating system can work, I simply wrote one: GCVote. It is a very basic 5 star rating system without detailed definition of the categories. But it integrates seamlessly with GC.com and has thousands of happy users. If you look at caches in Germany, where GCVote is heavily used, you will see that even this simple system seems to work. To me, GCVote proves most arguments against a rating system wrong.

I wrote two small Greasemonkey scripts for two of the issues mentioned in this thread. osm4gc adds links to OSM maps to the details pages on GC.com. osmCoords works on www.openstreetmap.org and changes the behaviour of the search field. The script recognizes common formats of coordinates and moves the map to the indicated place. This is one of the features that t4e was missing on the site.

Thank you for that information. I was using version 5 for Linux and forgot that the stable version is 4. Well, it was a very small problem/bug and should be fixed now. Please try again!

Yes, that's more or less what I said in the beginning. But the actual wording that I chose was not very good and I removed that clause to improve trust in the system. If there ever will be another better or more popular solution that can work with the data from GCVote, I will do my best to provide an easy way for each individual user to move his votes to the new system.

Good Lord, you're not supposed to give me your password for geocaching.com to use GCVote. Since a few people abused the open database, I had to introduce accounts for GCVote. These accounts and their passwords are totally independant from anything. There are no real security risks, if you choose a password that is good only for GCVote. In the worst case I could use it to alter your votes, but I can do that anyway, as it's my database. And to the people that have all these nice arguments why a rating system cannot work, I would like to point out that GCVote obviously works for a lot of geocachers. It may not work for every geocacher and it may not work for every cache, but it works for most geocachers and for most caches. And its a very simple system. I would expect a more elaborate system implemented by Groundspeak to be of even more use for even more people.

I was a bit wrong about Chrome and GCVote. Even though Chrome's userscripts are not powerful enough for GCVote, real extensions do have the neccessary permissions *and* consist mostly of Javascript. You can find GCVote for Chrome in Google's library of extensions. There may be some small bugs left.

It allows you to rate/recommend geocaches. It adds a small control to all pages on geocaching.com to display average ratings. Imagine that Groundspeak added a simple 5-star rating for caches to the site. When you surf with GCVote installed, the pages look just as if they did that. For more information please visit gcvote.com.

I don't think so. All browsers prevent Javascript to access data in non-local domains (cross-site-scripting). Greasemonkey adds an exception and gives additional rights to the installed scripts. The build-in userscripts of other browsers do not get these additional rights. But I may be wrong, I just don't want to spend that much time installing and testing all the different browsers and all the different plugins that may or may not allow cross-site-scripting. There are updates to these browsers and plugins all the time and the required features are seldom well documented. When I hear of a promising solution for another browser, I try to test it and would do my best to make neccessary changes to GCVote.

No, you install IE7Pro (which does not only work with IE7). Then you install the compatibility script and GCVote. IE7Pro replaces Greasemonkey in this setup. There will be real installation instructions when the next version is released. For now I it's just beta and there may be issues that could lead to a different setup.

dakboy, only unethical administrators can read passwords? Yes, that is true. Only unethical administrators would *want* to read passwords. But you cannot be sure of the ethical qualities of any service's administrators. I could implement additional security layers to prevent me from reading passwords. But even after that, I could still disable those layers and sniff passwords anyway. Please explain how to make this system secure without delegating the security to an external service, as that service could break the security itself. HTTPS/SSL does not help as long as I have access to the server's processes. Hashed passwords in the DB do not prevent me from sniffing your input. Even if there was a way to implement perfect security (and there is none), it would be overkill for a system like GCVote. Did you check if Groundspeak implements any of your ideas? Let me "spout" this again: Your bank, as an entity, can sniff your password, only the individual employees can not. If all employees worked together, they could sniff your password. And there is no way to prevent that. Password *recovery* is a totally different matter. But as long as you are using your password, it can be sniffed. You seem to know a lot of good practices, but you should realize that they do not provide ultimate security.

3. Please do not use the same password for different services. Administrators really can read them! If you forget your password, you can contact me or you can take a peek into about:config, where the password is stored on your computer. (Again in plain text, as there can be no added security in encrypting it. I am very willing to discuss that point.) 4. One could set up a kind of proxy website that would read the information from geocaching.com and alters it. But Groundspeak does not allow that. Plus, the proxy server would know your password for geocaching.com... I still hope that Groundspeak implements its own rating system, as that is the only perfect solution.

As an Unix administrator with full access, I can easily alter the system to log your password when you enter it. The hashed storage only prevents extraction of the passwords in the case that the disc is stolen. In case of a web based service like GCVote, it is even easier: I only have to log the communication between your computer and my server. As I tried to explain, GCVote could encrypt the password on your computer, and only send a hash to my server. But in that case the encrypted password is the *effective* password. There is no way to make this really secure. I could also do what every Unix admin does: Copy the encrypted password, set a new password, do my stuff and copy the first encrypted password back into the password storage.

I am the author of GCVote and would like to comment on your points. 1. There are 2000 registered users and 500,000 ratings for 150,000 caches. But most of the rated caches seem to be in Germany. 2. GCVote will support Internet Explorer soon and you can used it with GSAK and other tools. 3. What is the difference between sending me a password and setting it yourself? As the service's administrator, I can easily access all your data for GCVote. But since a lot of users seem to have a problem with sending this password by mail, I will add a feature to change your password soon. 4. The installation requieres several steps, but they should be documented well enough to execute them without deeper knowledge. 5. True. 6. I would be glad to help you with your installation. And I cannot understand your privacy issues. You are not supposed to send a relevant password (like the one for geocaching.com) to me. Every administrator of every service can read your password for that service. (If the password is encrypted on the client, you can regard the encrypted password as the real password.)

I guess that you could write a Greasemonkey user script to add this (or any other) feature to GC.com when it is displayed in your browser.