jri

Only if someone else can supply the stats! ... but I am thinking of a SideTracked widget that will show live train times at the nearest station!

Having spotted a load of Church Micro caches appear in my area (mostly thanks to @Leonards193), I wondered how I was doing in the rankings, and had a look at @BaSHful's Church Micro Statistics page. It turns out that I'm not exactly doing great compared to some people, but the award badges caught my eye, and I thought it would be good to be able to keep track of how I'm doing when I look for a Church Micro cache. I've written a Greasemonkey userscript that lets you see these award badges automatically on Geocaching.com. What it does is this: Displays your own award badge on the Your Profile page. Displays your own badge on cache listings for Church Micro caches (but not other caches). Display's other people's award badges at the top of their profile pages. Shows the number of Church Micro finds your friends have made on the Your Friends page. Hopefully there are a few other people out there that will find this fun! To find out more and install the script, go to OpenUserJS.org/scripts/JRI/Church_Micro_Stats Thanks go to @sadexploration for starting the series, and @BaSHful & @Andy33 for providing the statistics. BaSHful has also been very helpful in tweaking his web server to help me get the script to work nicely.

It looks like OpenUserJS changed all their download URLs this morning, and although they say they're redirecting the old links, it doesn't seem to be working. I've gone round and updated all the links on my pages though, so if you go back to http://geo.inge.org.uk/gme.htm#install now, the install button should be working again. Once you've reinstalled by this method, Tampermonkey should auto-update the script in future.

I've released another bugfix update for GME: The main outstanding issue is now that different pages get different GME configurations, depending on whether or not they are served over http or https. Unfortunately, I haven't got the time to fix this at the moment (new baby due yesterday!) but there's a chance it may fix itself if Groundspeak change more of the site to https. You can download the new version at https://openuserjs.o...ap_Enhancements Documentation is at http://geo.inge.org.uk/gme.htm GME is compatible with Chrome as a native extension, but because it isn't in the Chrome store, you may have difficulty installing it due to Google's monopolistic security policy. If you have problems using GME with Chrome, I recommend installing Tampermonkey from the Chrome store, then using that to install GME (instructions). At some point I might try converting GME to work in the store, but it's not high on my priority list at the moment.

Sadly I must concur. Firefox 30, Greasemonkey 1.15 and GME 0.7.0 Can't even blame it on Groundspeak this time: the behaviour of one of Geonames' web services has changed that GME was using for the search function. I'll have a fix out shortly... In the meantime, use GME's configuration screen to disable Enhanced Search, and you should be able to use the standard functions as normal.

Thanks, this patch makes Search work again for me (except for GC-Code searches, of course). I believe the docs say, Enhanced Search will search for locations within the current country (only). I'm seeing GeoNames search results for US while viewing an Austria map, though. I'm glad the patch works. The GeoNames search biases towards the country you are looking at, but if there aren't many local places in the database with a similar name, you will still get hits from other countries. The search also prioritizes by size of settlement.Often you get hits from the US because America was settled by immigrants from all over Europe, and they tended to be unoriginal in choosing place names! If the place you are interested in isn't in the Geonames database, you can always add it in!

I tried installing FF24 ESR and started getting similar behaviour to you, albeit without the access violation messages. The Search function stopped working, as did Panoramio photos and spot heights, which also use GM_xmlhttpRequest. I guess something has changed in the internals of Firefox. However, I've now been able to come up with a fix that seems to work. I will put this into the next release (hopefully this weekend). If you can't wait, you could try editing the script. The GM_xmlhttpRequest() function call has to be wrapped in a setTimeout() function as below: 365: setTimeout(function() { GM_xmlhttpRequest({ . . . 379: }); }, 0);

Sorry, that is actually working. It's just that the search box on the map page looks for locations, not cache names. The message you saw means that the script successfully performed a search, but couldn't find a place called "Wizard's Hat" in either the Geonames database, or whatever location service Geocaching.com uses (I think they swap between several). What the GME enhanced search on the map page is supposed to do is this: Checks the Geonames database for the place you searched for, and gives you a list of possibilities (normally you don't get options). The search is prioritised by the country you are looking at on the map, so if you are browsing US caches and search for York, the first hit is in Lower Manhattan. If you do the same in the UK, you get the original city of York top of the list. Lets you search by GC-code (broken in v0.7.0, but will be fixed in the next release). Lets you jump directly to lat / lon coordinates entered in various formats. Lets you jump directly to British Ordnance Survey grid references. Lets you zoom in and out by typing something like "z 10" to go to a particular zoom level, rather than having to keep clicking the zoom button. Lets you plot a precise point on the map, by typing a "p" then the coordinates (e.g. "p N51 23.123, W2 35.678"). If you want to search for a cache using a keyword in the title, you need to use the Seek a Cache page. This normally gives you the option of a "Name starts with..." search. GME adds in a custom Google keyword search, plus geographic searches centred on freeform coordinates, OS grid references, or the location reported by your browser's Geolocation function.

So I seem to be the only one for whom Search isn't working even with 0.7.0 If Configure, Other, Enhance Search is on, clicking on the Search icon or pressing Enter with any Search string specified does nothing, except the following message in the Console: [19:57:25.096] Greasemonkey access violation: unsafeWindow cannot call GM_xmlhttpRequest. [19:57:25.095] "GME: New JSONP" Any ideas what might be wrong? Erm. Not really. The "New JSONP" message tells me that you have successfully installed the new version, and that your browser (Firefox?) claims to support the GM_xmlhttpRequest function. Greasemonkey (and similar extensions for other browsers) provide this function to allow userscripts to request data from other servers. Normally, the Same Origin Policy means that scripts on web pages can only request data from the servers that they came from. GME used to use JSONP to get search results, photos and height information from elsewhere than Geocaching.com. When Geocaching.com started using HTTPS connections for the map, it was no longer possible to fetch JSONP data from non-HTTPS servers, and I switched GME to using GM_xmlhttpRequest, if available. The "access violation" message tells me that for you, GM_xmlhttpRequest isn't working. For security reasons, only userscripts are allowed to use this function, not ordinary javascript running on a web page. GME is a userscript, so should be able to use the function fine, but it does also insert some scripts into the web page which run with lower security privileges. They would generate that error message if they tried to use it, but the script is designed so that this shouldn't be a problem. However, I haven't been able to replicate the error using GME on any of my browsers, and I don't understand why you're getting different results to everyone else. One possibility is that you have other scripting or security add-ons installed that affect how GME runs. Another is that you are using different software versions which behave differently. You haven't answered my question as to which browser and userscript manager you are using. Knowing that would help start to identify the problem. It would also help if you checked that you have the latest updates.

I'm not sure what's causing this. In the latest Chrome update, Google have started automatically disabling extensions that don't come from the Chrome Store. However, installation by dragging and dropping the script into the chrome://extensions window still works fine for me, and the extension is still there after quitting and restarting. Potential workarounds could be to enable developer mode in chrome://extensions, or to install Tampermonkey from the Chrome store and to use that to install GME. Let me know if you have any luck!

I tried this when it was first published, and it worked. Now I actually want to use it for real, and it doesn't work, I just get a downloaded file. I'm using Chrome Version 35.0.1916.114 m & GME v0.7.0 This still works in Firefox, but I've verified that I now get the same problem in Chrome v35. I'll add it to the list of things to fix. At least it looks like I can pin it down to one area of code. For things like markers and routes that you've drawn on the map, you can mostly click on them to get an option to remove them again. There isn't a way to do this for objects that you've dragged and dropped onto the map. It's on the to-do list, but not a priority at the moment.

Glad to hear the search function is working for you too. Unfortunately, GME can't easily work with offline maps. This is because of security restrictions built into web browsers to stop websites linking to your local files. In theory though, if you have got copies of the map tiles stored on your local machine, you should be able to set up a local webserver and point GME at that. I can't really advise on how to configure this, because it depends on how you have stored and named the map tiles, and how your local webserver is configured. However, the information on this page should let you figure out what you need: http://geo.inge.org.uk/gme_config.htm One thing that GME won't be able to do is access offline maps stored in sqlite files (even via a local webserver). It needs access to the raw files, and hasn't got the logic to find them in a database or archive file.

Unfortunately it looks like userscripts.org is down long-term, so I am going to be using OpenUserJS.org from now on. Although I can still get onto USO using port 8080, I can't edit the script or the information there any more, so I can't automatically divert users across to new versions of GME. Bizarrely though, the install counter on userscripts.org has started working again, just when everything else has failed! As far as I know, OpenUserJS should support automatic updates - but we'll have to see what happens when I do the first update! Either way, I will try to keep the documentation at http://geo.inge.org.uk/gme.htm up to date with the best information about downloading and installation.

It works for me! I can confirm that Search doesn't work if GME is enabled. Typing anything into the search box and clicking on the magnifier icon does nothing at all. After disabling GME (and refreshing the page) Search works as normal. I'm running GME v0.7.0. As I said before, I need more clues! Searching from the map in GME v0.7.0 works fine for me in Firefox, Chrome (with & without Tampermonkey) and Opera Classic, with the exception of searching by GC-code (and I've got a fix for that ready for the next release). If it's not working for you, I need to know what you are searching for (different search terms work in different ways), which browser you are using (they have different restrictions), and whether any error messages appear in the browser console. It's also helpful to know if you are using any other scripts at the same time. By the way, rather than disabling GME totally, you can just turn off GME's enhanced search function from the "Other" tab in GME's configuration screen.

It works for me! Enhanced searching was one of the things that was broken by the recent website update, but should have been fixed in GME v0.7.0. If you have already updated, it could be that you still have an old version installed too. I will shortly update the troubleshooting pages to cover this possibility. I have noticed that searching by GC-code is still broken - I will fix this in the next update. If the above doesn't help, you will have to give me some more clues: What are you trying to search for? Which search page are you using (geocaching.com/map or geocaching.com/seek)? Which browser are you using? Downloads: https://openuserjs.o...ap_Enhancements Main documentation: http://geo.inge.org.uk/gme.htm Troubleshooting: http://geo.inge.org.uk/gme_trouble.htm Custom map examples: http://geo.inge.org.uk/gme_maps.htm Custom map technical configuration: http://geo.inge.org.uk/gme_config.htm

Erm... dunno. But I've re-written my troubleshooting guide for GME, which might help. Links for documentation are as follows: Downloads: https://openuserjs.o...ap_Enhancements Main documentation: http://geo.inge.org.uk/gme.htm Troubleshooting: http://geo.inge.org.uk/gme_trouble.htm Custom map examples: http://geo.inge.org.uk/gme_maps.htm Custom map technical configuration: http://geo.inge.org.uk/gme_config.htm

Could you let me know the GC-code of the cache(s) you're trying to display? Also, on the cache page, please would you right-click on the "View Larger Map" link and copy and paste the link address too. Probably best to send the info in a personal message via my profile though, as that address could contain the corrected coordinates and give away the cache location! NB The map page isn't intended to automatically display corrected coordinates for every cache. You have to click through from the cache listing, using the View Larger Map link, or use the drag'n'drop technique discussed previously.

That sounds cool but it doesn't work for me either. I can drop the icon; it creates a file called "download" in my download directory. To see the waypoints on the map, you need to drop the icon onto the map itself, rather than somewhere random on the web page. That said, if you rename that "download" file to something with a .LOC extension (e.g. "waypoints.loc"), you ought to be able to import it into mapping / GPS software (or convert it using GPSbabel if your app doesn't understand .LOC files). You can also give it a .TXT extension to get it to open in Notepad if you just want to see what data is inside.

I downloaded the latest update from your link below. I'm running it on Firefox 20.0.1. I understand that the problem with the corrected coordinates isn't fixed by that update. But either I'm not understanding what I'm supposed to do in this workaround or I'm not applying it properly. For clarification's sake, can you tell me what the "main map" refers to? There are two maps on the cache page. Is one of them the map you are talking about, or do you mean we should open up a "search on map" page? Also, we used to have the option to label the caches on the map with their GC number or their name. When I click on the option to label caches, they're labeled with the GC number, and I see no option to switch to the cache name. Is this by design, or is it something else that broke with the latest geocaching.com update? I might as well take this opportunity to say that I love this greasemonkey script. It has made so many things so much easier for me! Thank you. As of v0.7.0, display of corrected coordinates in GME should be working without the need for a workaround. If you visit the listing page for a cache that you have correctted the coordinates for, or that has additional waypoints, these should be displayed on the second map on the cache page, just above the logs. You should be able to click either the "View Larger Map" link above that map, or the "Geocaching.com Map" link at the top of the list of online maps, to see those waypoints on the main map. By this, I mean the full-screen map at http://www.geocaching.com/map You should also still be able to label caches with their names. On the main map page, click the gear icon to bring up GME's configuration screen. On the "Other" tab, select "Names" rather than "Codes" for the Labels option, then click Save. The only thing broken here by the update is that you are supposed to see the same GME configuration across the whole site (you can also get to the Configuration screen from the Profile menu in the website's main navigation bar at the top of each page). Since the update, the configuration for the main maps has been independent from that on the rest of the site, and would have reset to default settings, which is why the labelling feature switched off for you. I'll also explain the drag'n'drop function that worked around showing corrected coordinates. It isn't necessary as a workaround any more, but it's still very useful. At the top of each cache listing, there is an icon showing the cache type, just to the left of the title. When GME is running, this should appear with a box around it, and when you move the mouse over it, the cursor should change to show that you can drag it. This icon can be dragged onto any of the maps that have been enhanced by GME, to display all the waypoints for that cache (including corrected ones). If you have the main map page open in another tab, you can drag the icon there. If you have another cache listing page open, you can drag the icon onto the larger of the two maps on the listing page, so you can see two nearby caches together on one listing page. This should also work on the TB tracking maps, and the planning map that shows free spaces for hiding caches. You should even be able to drag the icon into other programs, e.g. a text editor, to see the waypoint information in .LOC format. Hope that helps!

Not sure if you might want to also document the {x100} URL template parameter substitution. Done!

I've uploaded v0.7.0 of GME to OpenUserJs.org, which hopefully will fix some of the recent problems: I've put in a workaround for the security problems, so functions like showing spot heights or Panoramio photos should work without you having to tweak security settings for each browser session. The documentation at http://geo.inge.org.uk/gme.htm now gives the new download location. I've also updated the instructions for installing in Opera Classic, to include making userscripts work with HTTPS. Clicking through from a cache page to show its details on the main map should work again. The cache information is now encoded into the link to the map, rather than by browser localStorage. The main outstanding issue is that GME's configuration is not shared between HTTP and HTTPS pages. This means that people who had custom maps loaded will initially only see them on cache pages, not the main map. As a workaround, the JSON configuration string can be exported from GME on the cache page to GME on the main map, as per my previous post. The new script can be found at https://openuserjs.o...ap_Enhancements Let me know if I've managed to introduce any new problems!

"Dein Profil", wenn Sie haben die Website-Sprache auf Deutsch eingestell! It's one of the options that appears underneath the Geocaching logo, on most pages on Geocaching.com apart from the main maps page.

Two more problems with the same cause: GME uses localStorage to store its settings, and also to pass information about corrected coordinates between pages. LocalStorage is not shared between websites for security reasons. Unfortunately, web browsers treat the http and https versions of a website as totally separate. As geocaching.com has started using https connections for the main maps but http for the individual cache pages, GME no longer sees the same settings on both pages. I'll add this to the list of things to fix, but in the meantime there are a few more workarounds: To show corrected coordinates on the main map: open the page of the cache you want to view, and open the main map in a different tab. Drag and drop the cache icon from next to the title of the cache listing, onto the main map. Any waypoints or corrected coordinates should be shown (you can do this with more than one cache too). To find your old custom map settings: open a cache page (or any other page on geocaching.com that has an http connection). From the Profile menu at the top of the screen, choose the "Geocaching Map Enhancements" option to open the GME configuration dialogue. From the "Manage Maps" tab, click "Export custom maps". Select all the JSON code that pops up, right-click on it, and copy it to the clipboard. Open the main map page, click on the gear icon to open the GME config dialogue again, and go to the Manage Maps tab. Past the JSON code into the "Mapsource" field and click "Add", then "Save". You should be able to add all the maps back in one go this way, but might need to go back to the Manage Maps tab to remove duplicates.

I don't use Garmin communicator, so I can't tell if it's the same issue, but there's a thread about it open in the Website Bug Reports forum.

Just a guess, but would this problem have been caused by geocaching.com switching over to https connections on Tuesday's update, and as a result falling foul of web browsers' security policy of blocking mixed (secure/insecure) content?