jri

If you are using the Geocaching Map Enhancements add-on, and you are in the USA, you can get data from the Nexrad weather radar as an overlay to the geocaching map. See http://geo.inge.org.uk/gme_maps.htm for instructions how to add custom maps and overlays. The configuration code for Nexrad is {"alt":"Nexrad Weather","tileUrl":"http://mesonet.agron.iastate.edu/cgi-bin/wms/nexrad/n0r.cgi", "layers":"nexrad-n0r-900913", "format":"image/png", "transparent": true, "attribution": "Weather data © 2012 IEM Nexrad", "maxZoom":16, "overlay":true} Nexrad doesn't give a forecast as such, but it lets you see the storms coming in.

Thanks for letting me know about this. There are a few ways round the problem. Basically, you can either use a userscript manager like Tampermonkey (a bit like Greasemonkey, but for Chrome), or install the script manually. I've updated the installation instructions on the script's homepage at http://userscripts.o...pts/show/109145 and put detailed instructions for Chrome at http://userscripts.org/topics/115329 Alternatively, you can try using GME with Firefox or Opera. I've even started getting the script working with Internet Explorer!

This sounds like an interesting idea to me. Some of the security concerns could be got around by showing a preview of the track before making it public,or by allowing tracks to be shared only with friends, but I think the problem of spoilers would always be an issue. Also, there would be the technical challenge for Groundspeak to manage all the track data: depending on the settings you use to record your logs, the files can be quite big. I do like the idea of being able to show track logs on the map though. I've already got a Greasemonkey script that will let me drag and drop a GPX file onto the map to see the waypoints it holds. In the next version, I'm planning to extend it to display GPX format tracks and routes. That will give similar functionality to what FraenCache suggested, but without the tracks actually being shared (which removes the privacy issue). You can always email GPX files to your mates to share them, and I guess that that's not going to be any worse a spoiler than phoning a friend.

According to this post, so long as you've signed the log book, Groundspeak are happy with you logging them online. You're just not allowed to see the listing page for a Premium cache unless you're a Premium Member. This post shows how to do it (I've not tried myself, but assume it still works). When you log online, it would be normal to use the date you actually found the cache.

Does the icon work if you just click on it normally (i.e. don't try to open it in a new tab)? The configuration screen is supposed to open in the same tab as the map. If that doesn't fix it, post which version of Chrome you see, and whether there are any error messages in the Chrome console (press Ctrl-Shift-I). NB It's normal to have a load of error messages about viewport arguments.

These requests were "map.info" in Mapgeust and "9322.info" (or maybe the other map tile number) in OSM. The lattered requests failed always. @GWRoss: Look in the Net tab of Chrome's console. The requests are made every time you move the mouse over a new tile on the map.

Unfortunately the problem is that you don't live in America, and Mapquest only serve up high resolution aerial photos in North America. Your options are limited: 1) Move to North America; 2) Zoom the map out to the point where you can't see any detail anyway; 3) Get Premium Membership of Geocaching.com, so you can use Google's satellite view; or 4) Install an add-on script like Geocaching Map Enhancements that lets you choose other sources of maps and aerial photos.

Well, I toyed around with Chrome's "Inspect element". This is what I discovered: OSM map: Request URL:http://a.tile.openstreetmap.org/14/9322/4733.info?callback=grid Request Method:GET Status Code:404 Not Found Mapquest map: Request URL:http://www.geocaching.com/map/map.info?x=9321&y=4733&z=14&k=gtHK...EhU81&ep=1&callback=grid Request Method:GET Status Code:200 OK grid({"grid":[" ",...."], "keys":["","(42, 34)",... "data":{"(42, 34)":[{"i":"GC36BFB","n":"OMSAUT"}],"(43, 34)":[{"i":"GC36BFB","n":"OMSAUT"}],... ]}}); I wonder, whether openstreetmap.org is supposed to know the name and GC-code of the cache-bubbles that are displayed? OTH I really don't know what I'm doing, so this may be a completely false alarm No, you are correct: this is a valid bug. Unfortunately, it's intermittent and I haven't quite worked out the sequence of events that reliably triggers it. It doesn't just happen with OpenStreetMaps - sometimes the website asks Mapquest or one of the other map servers for the cache info. I've also seen it in Opera and Firefox, so it isn't specific to Chrome. I think it's been reported on a few threads now, but I've not noticed the management pick up on it yet... The URLs you've quoted are related to the URLs of the map tile that you moved your mouse over. They are supposed to be derived from the geocache icon tiles, but sometimes the website gets confused and uses the basemap tiles - hence the requests to OSM et al. It seems to be related to the way the Leaflet API swaps layers on the map (which is why zooming or changing map source helps). Although I'm not sure what the underlying problem is, I did come up with a workaround. It is possible to write a script that intercepts the dodgy data requests and redirects them to the correct server. I've added this bugfix into the latest version of my Geocaching Map Enhancements userscript (which has various other useful features too). Unfortunately, this bug is not the end of the story. Even when the website is using the correct URL, it seems to get a nil response back fairly often, which could be a server loading issue. Once the website fails to get the data for a tile, it doesn't seem to try again (although panning to new areas may work).

There should be a scale already. If you're using Google Maps, it should be at the bottom-right of the main Geocaching Maps page. On the cache pages, and on the main map if you've set your map preference to Leaflet, it's at the bottom-left. If you can't see it, post details of which browser you are using.

The API just provides a standard method for a web page to get location information from a web browser. It's up to the browser to figure out what that location is the best it can. Browsers are native apps, so they can use whatever hardware the operating system made available (and various other methods of guessing). Mobile operating systems tend to know about GPSrs, but whether their security model lets the browser get at the data is another matter. When I was writing widgets for a Nokia S60 platform, you couldn't get at GPS info through the web browser, you had to write a native app. However, I've tested the API using Firefox Mobile and Opera Mobile on an Asus Transformer TF101 (Android 4.0.3) and an HTC Desire (Android 2.2), using my GME script. In both cases, it worked fine with the internal GPS on the device and the result was perfectly adequate for geocaching.

Erm, it does... On the Geocaching Maps page, there is a "Find my location" button (crosshair icon) in the top-left of the map. It only appears if your browser supports the Geolocation API and if you have selected Leaflet rather than Google as your map preference (if you are a Premium Member). It's a bit of a gimmick on a desktop browser (as you're likely to be sat at your home location anyway), but it's much more useful on a mobile platform like a tablet. How well it works depends on your browser and operating system. While you may have GPS hardware, your browser needs to be able to figure out how to connect to it. Mobile browsers tend to be good at that. If the browser can't figure out how to connect to GPS (a common Windows issue), it can still try by looking up your IP address (might be 100s of miles out) or the details of nearby cellphone or wifi signals (accuracy between several miles to 10s of meters). Geocaching.com doesn't use the Geolocation API directly. It just uses the widget built into the Leaflet API. One problem with the way it does this is that it does not allow a long enough timeout to wake up the GPS hardware on my Android tablet and wait for the first fix (this is a GC.com flaw, not a problem with Leaflet). I've built a fix for this issue into my Geocaching Map Enhancements userscript. GME also goes one step further and has an option to continuously update the map location. If you're getting location data from GPS, this turns Geocaching Maps into a moving maps app! There's no reason why Groundspeak couldn't add a similar function to the Google Maps view. As Google Maps is default for Premium Members, it's a bit odd that you get fewer features! It could also be used elsewhere on the website, so that e.g. listing pages show distance from your current location, or you could do a location-based search from the Hide&Seek page. I might look at adding some of these features to a future version of GME...

It's not a bug as such, but I wouldn't go as far as saying it was by design either! Let's just say it's not a feature I've implemented yet... When you drop a file in, you ought to at least get some information about each point as a tooltip when you hover the mouse over its marker. However, what information you get is a bit inconsistent depending on whether you dropped a LOC file (giving the name) or a GPX (giving the GC-code). I'll see if I can make the tooltip more informative for this release, and maybe look at something more complicated in a future update. I'm a little wary of causing confusion between popups from points you drag onto the map, and the usual popups from the live cache data - especially when both relate to the same point. BTW - you should also be drag able to drag the title of a cache from a listing page onto the map page, to display markers for it and any associated waypoints, using corrected coordinates if applicable!

I've got GME v0.6.0 nearly ready to go, but it still needs some testing. If you're feeling brave, you can try out the preview at this link: http://geo.inge.org.uk/GeocachingMapEnhancements.user.js The new version should add in support for dragging and dropping GPX or LOC files onto the map for display (in browsers that support HTML5 drag'n'drop), improve display of Geograph photos, add Panoramio photos, and move the cache list function onto the i menu, rather than giving it its own icon. It will also work around the website bug that often stops geocache details being shown when you point at cache icons, as well as the Opera and distance measurement bugs mentioned in the posts above. This version should also run under Internet Explorer 8 using the Trixie extension. Unfortunately, the amount of work I had to do to make it work with IE8 means that there's a fair chance I've introduced new bugs. Hence I'm posting the preview here for early adopters. If you try it, please send me a message through my profile if you do come across any bugs. If I don't come across any I can't fix, at the weekend I'll update the official version at userscripts.org to v0.6.0, and update the instructions to match.

There are actually a whole host of independent problems here: Sometimes the server is slow at serving up tiles from the map's geocache layer, so the icons either appear slowly, partially (chopped in half on the edge of tiles!) or not at all. Sometimes the server is slow at serving up the data about caches. As you move the mouse over the map, the website only asks for data about the places you move the mouse to, so if the response is slow, you don't see the icon change shape before you've moved the mouse away. If you click on the icon before the data has been received, nothing happens. There is a bug on the website that means it sometimes uses the wrong URLs for the geocache data (i.e. it asks MapQuest or OSM, rather than Geocaching.com!) This means that the cache details don't pop up at all. When zoomed in, the clickable hotspots for the icons are smaller than the icons themselves. This means you might think you clicked in the right place, but you didn't. There's not really a lot you can do about the first two problems. The third one you can work around by either changing the zoom level or switching to a different map source. I've also got a techy fix for it that I will build into the next version of my Geocaching Map Enhancements script. I'm not sure if I can fix the last one with a script - you just have to aim your clicking in the middle of the icons. It would be nice if it all worked out of the box though, wouldn't it?

After a quick bit of googling, this appears to be a bug in the JQuery Mobile javascript library, that has been triggered by the Opera 12 update. It seems to be fine in other browsers. See here for the gory detail: https://github.com/j...ile/issues/4521 At some point, the JQuery folk will built a fix into their library, eventually Groundspeak might update the version of JQuery Mobile they use on Geocaching.com and the problem will go away. In the meantime, you will be glad to hear that there is a workaround: In Opera, load Geocaching Maps, then open the Dragonfly console (Ctrl-Shift-I). Click on the 'console' tab, and type in the following: $.support.cssTransitions = false; After that, you can close the console and the GME config dialog should pop up as normal. The downside to this is that you need to redo it each time you reload the page (if you want to use the config dialog, that is). Alternatively, you could just switch to Chrome or Firefox I am currently working on GME v0.6.0, which will include this workaround, fix various other bugs, add some new features, and possibly even work in Internet Explorer!

It looks like someone else has been thinking that a Geocaching app for Pebble would be a good idea. It's one of the examples mentioned in the preview of the Android SDK at http://developer.getpebble.com/

I guess so. It's not something I've tried, as I don't have a standard GPSr, but the instructions at http://mobac.sourceforge.net/MOBAC/README.HTM look hopeful. You need to read the bits about using custom WMS map sources with MOBAC, and set up a configuration file using the parameters from the GME configuration code.

I was going to report this myself, once I'd figured out why it is happening. What I've figured out so far is that normally, when you move the mouse over each map tile, the web page fires a request to the geocaching.com servers for data about any caches that may be in the area covered by that tile, and uses it to pop up the cache titles and descriptions. The URL for the data it asks for is based on the URL of the map tile. It is supposed to use the map tiles from the geocache icon layer but from time to time it uses the tiles from the base map instead. This means that the web page starts asking Mapquest or OpenStreetMap for cache details, rather than Geocaching.com What I've not yet figured out is precisely why this happens. It seems to be related to adding or removing layers on the map, which happens when you zoom, change map type, or add different overlays (like filtering out your finds). However, it doesn't happen every time you do one of these things...

Details of my configuration (browser and version, application version, etc.):Firefox 12.0 / WinXP, Opera 11.64 / WinXP Chrome 19.0.1084.56 m / WinXP [*]Specific steps leading to the observed behaviour: In Geocaching Maps, zoom in to level 14 or greater[*]Details of the observed behaviour: When you move the mouse over a geocache icon, the hot spots (the regions where the mouse pointer changes, the cache name tool-tip is shown and the icon is clickable) are only in the middle of the cache icons and do not extend all the way to the edges. Where cache icons are close enough to overlap, this means that the mouse can sometimes appear to be over the top icon, but only the details from the bottom icon are shown. This bug also makes the website harder for less dexterous people use. [*]Details of the expected behaviour, i.e. what you believe should be happening instead: I believe that at zoom levels 14 and greater, the hot spots should be made the same size as the cache icons, so that if the mouse is over any area where icons overlap, the tool-tips for all the icons will be displayed. This already happens at zoom levels 13 and smaller, where the cache icons are smaller and the hot spots cover the full extent of the icon.

Not quite - I think you may have mixed up my reply with one on another thread! In the past, USB used a master/slave architecture, where only the master (or host, i.e. a computer) could set up a connection to a slave device (memory stick, bluetooth dongle, GPSr, etc). OTG is the technology that lets one device act as both a master and a slave, depending on what you plug it in to. Old Android devices were just slaves - you could plug them in to a computer and read them like a memory stick, but they weren't able to use other USB peripherals. Newer Android devices have OTG: you can still plug them into a computer as a slave, but you can also use them as a master for other devices. AFAIK OTG is only supported in Android 3.1 and above. From what I can see, the OTG adapters only change the size of the USB socket, so that you can physically plug in a standard device. I don't think they will add OTG functions if your tablet didn't support them in the first place. I don't think so. I can use a bluetooth GPSr via the internal bluetooth on my Asus Transformer, and I can use the same GPSr with a D-Link DBT-120 bluetooth dongle on my PC. However, when I try plugging the dongle into my tablet, nothing happens... If your tablet supports OTG, then the hardware should be compatible, but you probably need driver software installed on the tablet to tell it what to do next. Unfortunately, I'm not sure that these drivers exist - but hopefully someone can prove me wrong.

Possibly, depending on your tablet. First you need to check that your tablet has the right hardware. It has to be able to act as a USB host. If it can read a memory stick, that's fine, but some devices just have USB so they can act as a peripheral for a desktop computer. Next, you need software that knows what to do with a USB GPSr. For high-end tablets that run Windows, that ought not to be a problem. I've not come across any Android software that can use a USB GPS, even if the hardware is physically compatible (probably because a lot of Android tablets have built-in GPSrs), and I don't have any experience of Macs. You may have more luck with a Bluetooth GPSr. I have got a Globalsat BT-338and a Qstarz BT-Q1000, which I have used with Windows and Linux laptops, a Palm Tungsten T3 PDA, and an Android tablet. The Qstarz GPSr also has a USB connection, but I've only got this working on Windows and Linux. For Android, there is a handy Bluetooth GPS app that makes either device work.

Miniature Panoramio photos, you can do already: click on GME's gear icon, go to 'Add more maps', cut'n'paste the code below into the box, and hit 'Add mapsource'. {"alt":"Panoramio", "tileUrl":"http://mt{s}.google.com/mapslt?lyrs=com.panoramio.all|pv:2|tag:piles&x={x}&y={y}&z={z}&w=256&h=256", "subdomains":"0123", "attribution":"<a href='http://www.panoramio.com'><img src='http://www.panoramio.com/img/logo-tos.png' alt='Panoramio'></a> Photos are copyrighted by their owners", "minZoom":0, "maxZoom":22, "overlay":true} That should add the Panoramio thumbnail overlay into your list of maps. However, the thumbnails are very diddy, and they aren't clickable. I'll have a look at how easy it is to use their API to properly integrate Panoramio photos into a future version of the script. Failing that, it would be easy to add an option to GME's Info tool to open Panoramio at the same coordinates and zoom level as the Geocaching map (albeit in a new tab).

Yes, same here. I just measured 500m (using the OS grid lines as a guide), when set to Metric it came out at 500m, but switching to Imperial and measuring the same distance came out at 149ft, measuring 1km came out at 304ft, but measuring 2km came out at 1.2 miles (which is OK). It looks like the conversion gets mucked up for anything less than a mile. My bad. Looks like I converted feet to metres, rather than the other way around It'll get fixed in the next update...

+1. Looks like a sound idea.

I've got one of these on order too. So far, they don't seem to have made the Pebble SDK public, but when they do, I'll have a look and see how complicated it would be to whip an app together. How would people see it working, bearing in mind the limited capabilities of the watch?