jri

OK. It can now do the distance measuring thing. And you can now search by GC-code from the main map page. And if you click through from cache pages to the main maps (using the "View Larger Map" link above the map), it should show additional waypoints and corrected coordinates, if present. If anyone feels like testing: v0.5.8 pre-release version is at http://geo.inge.org.uk/GeocachingMapEnhancements.user.js

So why not give it a hint, and get a better guess? I have also done some testing with Geonames and developed an experimental service for place name disambiguation. IMHO, the best approach is not to try to return a specific result given a search string. If the end user, provides enough information the algorithm will return an exact match, but rather than "guess" and return the most likely match when the amount of information is not specific, it should prompt for more information. It can do that using the geonames autosuggest API (that is what I did with my experimental service). For example, if I type in York, the service will pass what I have type so far to the service and return a list of about 20 possible candidates as a select list. I can then select the one that I want (i.e York, Kwazulu-Natal, South Africa) and get back the lat/long coordinates for the location I want. The two approaches are not incompatible. With an autosuggester, it still helps if you can sort the list of suggestions into a helpful order. Otherwise, if you're unlucky, you end up either having to scroll a long way through a list, or type the exact match anyway. The list of results from the default Geonames search comes ordered by some sort of relevance function - I'm not sure of the exact algorithm, but it seems to prioritise on rank in the administrative hierarchy, then population size. Using the bias by country makes the local results come at the top of that list. For my userscript I decided to use just the top hit for a couple of reasons: I wanted to minimise differences to the original interface, to minimise multiple network requests (i.e. not sending as you type, thinking of mobile users), and to retain the ability to fall back through to the original search engine rather than force a choice from the Geonames hits (so that you can still search by postal codes, coordinates and other strings that Geonames' database doesn't handle). Another possibility (for either an autosuggester or a first-hit solution) would be to sort the results list by distance. I tried that, but I thought it threw up too many irrelevant results; Geonames sort order seemed to work much better. Either way, there is a lot of potential to improve the current map search function.

It's still working for me... but I've written some troubleshooting tips that may help.

Actually, having done a bit of research into this, I think it is something that Groundspeak can and should improve on. This is the most likely case. Nothing about your home coordinates is passed to the service - just what you type in. With the old beta maps, the search function used Google's geocoding API. With the new maps, they host their own geocoder on the geocaching.com servers. I don't know whether they've got their own database, or if this is just a front end for another service, but I suspect the latter (if it was their own, couldn't it do fun stuff like searching for caches by GC code?) Most of the main geocoding services allow the results to be biased to a given location. Yahoo! PlaceFinder can limit results to a particular country, as can Geonames (which can also prioritise rather than limit). The Google Geocoding API can bias searches for a given region or set of coordinates. If Groundspeak is using one of these services, they have the potential to use these features to improve our search results. I have tested this out by writing a userscript that uses Geonames to check which country is being viewed, then do a search biased to that country. If you're looking at England and search for "Birmingham", you get the one in the Midlands, but if you were looking at America, you get the one in Alabama. You can still search for a specific one (e.g. "Birmingham, AL" or "Birmingham England"), but this should give better first-time results more of the time. If the search can't find anything relevant in Geonames, it hands back to the normal search engine, so you can still type in zip/postal codes and other search terms.

I've uploaded GME v0.5.7 to http://userscripts.org/scripts/show/109145 today. As well as fixing some bugs, this version has the following new features: Get spot height elevation data from the info tool Drop marker circles on the map (see earlier posts in this thread) Improved search function The improved search is worth a mention, as it's easy to overlook. It uses the Geonames service to figure out which country you are looking at, then uses the result to do a search biased to that country. What this means is that if you're looking at England and search for "Birmingham", you get the one in the Midlands, but if you were looking at America, you get the one in Alabama. You can still search for a specific one (e.g. "Birmingham, AL" or "Birmingham England"), but this should give better first-time results more of the time. If the search can't find anything relevant in Geonames, it hands back to the normal search engine, so you can still type in postcodes and other search terms. Also, you can now type "zoom 10", "z5" etc. in the search box, to zoom in or out to a particular level without having to click through every layer. Enjoy!

The latest version of the script is now nearly ready. I've fixed a few more bugs, the markers should now be removable, and the search box should work better (finding more results in the right country!) I've updated the test version at the link in post #79. If I don't spot any more bugs, I'll update it on userscripts.org in the next few days.

I've done a fair bit of caching abroad with smartphones and PDAs. Now I mainly cache using an Android phone, so this advice might not be directly applicable to the OP, but the same principles apply. The key thing is to get an app that allows you to store cache information offline (perhaps by importing a GPX file). It's also handy if the app supports offline maps - although check the quality of the maps available for the area you are going to. On Android, I use c:geo (which stores map and aerial photo snippets for each cache) with country maps downloaded from http://download.mapsforge.org/ Both because offline maps tend not to be as useful as online ones, and because you'll want to conserve power, I would only use the phone once you get to GZ, not for general navigation. As the other posters say, definitely plan ahead - print off maps from the website, or get a decent paper hiking map (shops like Stanfords are good for these), and mark on the rough locations. Read through the descriptions and recent logs before you go, to check which caches are going to be feasible for you. The density of caches is much lower than in the UK or Germany, so they tend to be further apart and visited less frequently. If you're on holiday with kids, the last thing you want is to go on a huge trip for a cache, only to find there's no sign of it, no-one's found it for ages and you can't understand the description! For the battery life problem, the main thing to do is make sure the phone isn't wasting power looking for wifi or mobile networks. Putting it into Airplane or Flightsafe mode is normally a quick way of doing this. If you have to connect to the mobile network (for texting, etc.) only re-enable it when you need to. There should also be a setting to disable Data Roaming, which should stop automatic services on your phone spending your money for you. Oh and the simplest method - switch the phone right off when you don't need it! Unless you're right out in the wilderness, there's generally some way of charging your phone. If you're driving, get a cigarette lighter adapter. Otherwise, get a european socket adapter, and look out for handy sockets in cafes, at the campsite shop, etc. If you're using an internet cafe, you might be able to top up from a USB port. I've tried using a solar charger (works OK for charging my old bluetooth GPSr, but the phone sucks it dry very quickly). You can also get "emergency chargers" that you feed AA batteries into.

Bizarrely, over the last couple of days I've had one Portuguese geocacher discover THREE of my trackables. I say bizarrely, because they had all been missing, for several years, in different countries... Methinks someone is entering consecutive tracking codes into the system - needless to say I've deleted the logs...

You've been doing that pesky eating and sleeping thing again instead, haven't you! It's painting the nursery that has really been taking the time... oh, and the day job That should now be working (from the same test link). When you click on a circle, there's now a link to remove it. I won't bother with anything special to remove them all, as I couldn't think of a logical place to put a control to make it happen and the refresh does the trick anyway. Nope. The cache details box appears anyway, and you get the right-click menu too. And I haven't figured out how to right-click on a tablet yet! I had a go at that too.

At the moment, I don't seem to be able to stop the site from showing the normal cache popup if you click on a cache. One workaround is to zoom in closer, so the offset from the cache is smaller. If you want to use the circle for spacing out new caches, the other alternative is to try marking your new location, rather than the caches you want to distance it from. Erm, no. I've not written that bit yet! I don't know whether folk would find it more helpful to remove them one at a time, or all at once?

There was some website downtime earlier today, but I'm not getting any problems at the moment. If you're still having problems, you will need to post some more details of what you (don't) see. Do you still get Mapquest and the standard selection of maps? Can you see any of the script's icons? Do any error messages appear in the Javascript console that aren't there with the script disabled? If Tampermonkey is unresponsive, you could have disabled it by accident, or there might be some other program interfering with it (a security or privacy app maybe?). You could try deliberately disabling Tampermonkey, then installing the script as a standalone Chrome extension to see if that works (remember to remove the 2nd copy again if you re-enable Tampermonkey)!

I'm not sure what (if anything) got updated when the site went down this morning, but the script still seems to be working for me! I've added a couple more bugfixes to the test version at http://geo.inge.org.uk/GeocachingMapEnhancements.user.js Did anyone try the "Drop marker" function? Is it useful? Does it work the way you think it should?

If you mean the message about checking settings, just click on the gear (configuration) icon, then OK the settings. Later versions only show the message once...

I think that you must have a problem with the GME configuration, as it works OK in Chrome for me. If you can see the GME icons in the bottom, click on the gear icon, then hit "Reset defaults". If you can't see the GME icons, you should be able to reset the configuration manually as follows: Make sure Chrome is pointed at Geocaching.com/map/ Press Ctrl-shift-J to get up the Javascript console, and click on the "Console" tab. In the console, type "delete localStorage.GME_parameters" (without the quotes, and making sure you've got the capital letters correct), then press enter. Do the same for "delete localStorage.GME_custom". Reload the maps page. Hopefully that should kick-start it into working again - let me know what happens. (For anyone with the same problem using Firefox or Opera, the instructions above should still work, but the console is Ctrl-Shift-K in Firefox, and Ctrl-Shift-I in Opera.)

I've got a new version of GME ready for testing, which is available at http://geo.inge.org.uk/GeocachingMapEnhancements.user.js This version tries to do the following: Improve the appearance of zooming when you are using the brightness control, and fix some related bugs. Make everything look like it did before when you're not using the brightness control (no black background). Allow you to reset to a default configuration when it's gotten fouled up. Add the ability to drop marker circles, as per Mark+Karen's suggestion. The circles function is part of the info tool (click the i icon, then "Drop marker". Currently the circles can be clicked to show their size and location - however, this means you can't drop one circle centred in another. Is that a problem? Also, I've not yet implemented a way of removing the circles. I won't put this version onto userscripts.org until I've had some feedback - so if you've had problems with the current version, try this and let me know what you think. One potential problem is that there is a site update scheduled for Friday morning. I may need to do some more tweaks if that breaks anything...

I think so... I'll have a play after work.

I can have a look at that, but it might be quite complicated to do. The way the website seems to work, the cache icons are just pictures on map tiles - you can't programmatically work out where they are. As you move the mouse over the map, your browser asks the server whether there are any caches near where you pointed and (hopefully) puts a hotspot on the map that corresponds to where the cache icon is. I guess this is done so that your browser only requests details of things you point to - rather than every cache on the map, but it means that the browser doesn't know where the caches are until you start waving your mouse around. That makes it hard to figure out where to put the circles... What would be much easier to code would be an option on the info tool to drop a circle at an arbitrary location on the map, so you could see if it went near any caches. Would that do the trick?

I'm not sure what caused your problem, as it has continued to work for me throughout. You are correct that the OS and Bing maps are linked - they come from the same servers. If it recurs, you could check whether the main Bing Maps website works for you. The brightness feature isn't the problem, since it wasn't present in v0.5.4 when you lost the maps. It is the cause of the background going black though - changing the brightness works by making the map semi-transparent over a black background. If v0.5.2 is working for you, v0.5.6 should too, but there is no need to upgrade - unless you want the extra features! For future reference, userscripts.org holds previous versions of the script, if you need to revert. There is a link to them at the top of the script's Source Code page. In Firefox you should be able to revert by just installing one of the old versions. In Chrome you have to uninstall first (from Spanner menu/Tools/Extensions), as Chrome doesn't let you down-grade. Another possibility is the script's configuration data getting corrupted somehow, possibly by using privacy software to wipe the "localStorage" data for geocaching.com. I'll have a look at adding a "reset to default" function to a future version.

Just for fun... with Geocaching Map Enhancements you can now make geocaching look like a real computer game, with the 8-bit version of Google Maps. To try it out, click the GME cog icon to configure, select "Add more maps", paste the code below into the Mapsource box, and hit "Add mapsource": {"alt":"Quest","tileUrl":"http://mt{s}.google.com/vt/lyrs=8bit,m@174000000&hl=en&src=app&x={x}&y={y}&z={z}","name":"quest","attribution":"<a href='http://maps.google.com/'>Google</a> Maps","subdomains":"01"}

GME v0.5.5 is available! Well, that is all working now, so you can now see aerial photos and more on the geocache listing pages, as well as the main Geocaching Maps page. I've also added in a warning triangle that pops up to tell you if you've zoomed in too far, and won't be able to see caches any more. As ever, for full details and installation go to userscripts.org

Thanks for the update, that's a real shame. I was just about to post something on here asking if there was any way you would be able to reinstate (as a minimum) the OS maps on the 'dynamic map' on the cache page - even though the dynamic map option has gone. That particular facility's usefulness in terms of positioning a puzzle cache's adjusted co-ordinates on a footpath or similar can't be underestimated. I know I can still look at the OS map on the larger map, but until Groundspeak align the position of the icon with the actual adjusted co-ordinates, I am always going to be guessing where the puzzle cache is on the map. I appreciate I sound like a spoilt toddler at this point ('I want, I want') and completely understand if it's not possible. I also realise this is extra work for you, but wondered if it is something you could have a look at given JUST how incredibly useful the dynamic OS map used to be. It was the only place you could see the adjusted icon on an OS map. Once again, thanks for your continued work on this project; the benefits of seeing the OS maps are highlighted even more these days when you compare them to the poor quality of the default. You are still my hero I'm working on it... but I'm a tad busy at home at the moment, so it will be a few more days yet before there's an update. From my point of view, the removal of "Dynamic maps" is actually an advantage. I had wanted to be able to add extra options to the cache page maps, alongside OS and Hybrid, but the Google API wasn't nearly as easy to extend. Although it looks bad at the moment, now that the Leaflet API (used on the main maps page) also powers the cache page maps, I should be able to re-use my code from the main page to add in a map selector relatively easily. Here's what I'm hoping to put into the next update: Map selection on cache pages Adjustable map brightness, to make cache icons easier to see (inspired by this script, but working in more types of browser) Fixed layout - since the 27 March update, the positioning of the map widgets seems to be all over the place Getting the icons in the right place is another matter - hopefully one that Groundspeak will fix themselves!

Today's Geocaching.com website update has removed the Google Maps API from cache pages (the "Dynamic Maps" feature) and replaced it with the Leaflet API and Mapquest. On the down side, this temporarily breaks GME and means no more satellite or OS maps on cache pages. On the up side, it will now be much easier for a future version of GME to add in a similar range of maps to what is available on the full-size maps page.

There was some website downtime earlier today, which might have caused the problem. It seems to be back to normal for me now... They're still working for me, so without more details, all I can suggest is to check you have the latest version of the script from userscripts.org, and read the previous posts in this thread to see if they give you any hints. Only if someone buys me a Mac Pro to do the development on!

There was a bug in v0.5.3 to do with setting the default map that might have stopped the GME widget appearing, if you had added an overlay. If you upgrade to the latest version it should fix that problem. If you've already got v0.5.4, you'll have to give me more info for a diagnosis. Do any error messages appear in the Firefox console? Are you using any other userscripts that work on the same page?

Erm, it's a bug Or, as I like to think of it, a limitation of Geocaching.com The reason the cache icons disappear is that you can now zoom some base maps in further than the geocache overlay. Different map sources work at different zoom levels. Some, like Google, work from Level 0 (where the world fits several times across the screen) to Level 22 (approx 1cm:1m). Other maps limit how far you can zoom in or out. In particular, the OSM family of maps can only zoom in to Level 18. The cache icons you see on the map are really just a layer of map tiles, shown as a transparent overlay. As Geocaching.com uses base maps that only go to Level 18, there's no point in them maintaining geocache tiles for higher zoom levels. There are 4 times more tiles at each level, so it would be a lot of extra effort to keep them updated. When I fixed the script to stop zooming beyond the limits of the base maps, I forgot it might mean that the more detailed map sources would let you zoom in too far for the geocache layer. I've got several options to fix the issue: Stop any map from zooming beyond Level 18, so you can always see caches, but might not get the ultimate detail the map can provide. Allow zooming as far as the basemap goes, for the people who want a really large scale view. Allow deep zooming, but pop up an alert when you go beyond the level that maps are visible. Any thoughts?