sbeelis

Dear HQ Last week we learned in the GSAK forums that you have decided not to make the Lab-API accessible to GSAK. This is of course your decision to make, but for us GSAK users it is a disappointing decision. I would like to outline why that ability is important to me in the hope of you reconsidering. My main tool when out geocaching is my GPS device. My main planning tool is GSAK. Even though I have to use the Adventure Lab app to actually solve the stages, I do not typically use it when planning or navigating. In areas where multiple Adventures exist, I often do them in parallel. Or I combine them with other caches or stages of other caches. For all of this, I loved the ability to get the coordinates of the stages of the various ALs. Getting the "parent coordinates of the overall adventure" (which you suggested as a workaround) does not help with this. One of the rationales why access was not granted was that you did not want third parties to be able to show the questions ahead of time. This, I can understand, and while it was nice to be able to read the question on my GPSr, finding the answer and only then switching to my mobile phone to answer the question (and saving battery power on it), the main motivation for me are precise coordinates for each stage.Maybe the API could be adjusted that third parties get the coordinates and descriptions but not the questions or even just the names and coordinates. This would allow us GSAK/GPSr users to navigate/plan outside your app without giving away anything you want to keep "geofenced". As an owner of an Adventure I miss all the tools I have as a cache owner. I do not get notifications when somebody finishes my adventure and writes a log. I have to go to the website or the app to read the logs. I have to go to the app to see the ratings. The Lab-API seems to offer a plethora of options to access logs, ratings etc that would be very useful and interesting to AL owners. I fail to see why these could not be made available to the owner of an AL using a third party application. The disconnect between Adventure Labs and Geocaches makes ALs less attractive to me. The inability to integrate them into my usual workflow feels like HQ is making me jump through hoops in order to play that new game (actually, it feels more and more like a separate game) and I fear that were it not for the "5 easy smilies" they would have gone the Waymarking way (i.e. be ignored by most cachers). I can accept that you want to keep the two platforms separate and prefer to spend your development power on other things than a better integration but please, pretty please give us the tools to implement that integration ourselves.

I asked the same question a few posts upthread and bootron's response was crystal clear: there are no plans of doing that.

Thanks for your reply (even if it is not what I had hoped for).

Yes, it was communicated in the GSAK forums. However, the GSAK people were told this change would be rolled out to the staging servers and could be tested there. Several people (me one of them) ran tests with our profiles on both staging servers and our profiles still worked, so we assumed the change would not kill the profiles generated by FSG. Today, when it went live, everyone there was totally surprised (and not pleasantly, at that). I don't know why we were told that this change could be tested on staging when in fact it was apparently not rolled out there....

@bootron I appreciate that these changes were required due to security and compliance issues. However, a lot of people liked having more detailed statistics than those supplied by geocaching.com in their profile and used GSAK+FSG or project-gc to generate those. Both sources created cool looking, well structured statistics pages by making use of "click" events and "show"/"hide" features of javascript/html. All of this no longer works. While I can see that some features of javascript were an issue, I don't see how the click/show/hide features could be a security/compliance risk. Is there any chance to just bring a subset of supported features back that would allow those cool statistics pages to keep working without opening the page up to security/compliance issues? This would be similar to the cache listings only supporting a subset of available html tags...

It's been a while since I browsed the forums. I was sure there was a suggestions forum for the iPhone app but for the life of me can't find it anymore, so I figured this would be the most appropriate place to post. If it isn't, can an admin please move it to the appropriate place? With iOS6 being available for download, I have a question/feature request about the available maps in the Geocaching app. Currently (Geocaching APp 5.0.1, iOS5.x) we can choose the following map sources: Street map: OSM or Google Street Satellite map: Google Sat or Google Hybrid I haven't yet updated to iOS6 but one of my friends has and according to him, the Geocaching App now also uses the Apple Maps instead of Google Maps (even though apparently the Google logo still shows). While the Apple Sat Maps may be great in the USA, here in Europe they leave a lot to be desired. Will we be able to continue using Google Sat maps with the Geocaching App? Ideally, we'd get to choose between Apple Sat maps, Google Sat maps and Google Hybrid. Thanks for answering my question and for considering my feature reqeust.

Our family will be visiting Japan for three weeks in March/April 2012. We'll be staying with friends in Tokyo at the start/end of our trip and we plan to visit Kyoto, Osaka, Nara (some other places might be added at short notice, but those are the "set" places). While our main goal is not caching, we would still like to find the odd cache while we're there. Can anyone recommend traditional/virtual/earth caches that are especially good/noteworthy? Ideally their descriptions would be in english, they should be possible to reach them using public transport and suitable for a family with small kids (one of them in a stroller). Any recommendations are appreciated!

The point of the guideline is that a potential hider may think about where he is going to place his cache and how he is going to maintain it. He may come to the conclusion that he won't place a cache he can't maintain (good); he may come up with a valid maintenance scheme that he will adhere to (good); he may make up some lie to get his cache published (bad). If the guideline is gotten rid of, potential hiders may not even realise they will place a cache that won't get the expected maintenance. I say keep it as it is. If you come across a badly maintained cache, you always have the option of alerting the reviewer to the fact using a "needs archived" log.

As an avid user of GSAK I, too, would find this an excellent idea. The ability to add (already possible) and delete (requested for) specific entries to/from the ignore (or potentially any other bookmark) list would be a huge improvement to the API which would make managing these lists and keeping them in sync with third party tools much easier. In fact, like GeePa, I would go even further than jholly: Let us create/query/delete/add to/delete from bookmark/ignore lists through the API! +3 votes

Since this feature seems to not be working at the moment (I can upload GPX files but they don't show on the iPhone), maybe disabling this feature on your web site would make it clearer that this is no longer working by intent rather than being a bug.

I am aware of that. Have you ever tried doing that for a 1000 cache PQ? I gave up after 3.5 hours... I don't know what algorithm it uses to determine which tiles it already has and which it still needs to download but from the time it takes to download this over a WLAN that it does it all over again for each cache, even if it is only 200 meters from the nearest one...

@Moun10Bike I can see your point. Still, just out of curiosity, how do you explain that you do not show who is watching a cache but you do show who granted it favourite points? (And I sure hope me asking the question will lead to the donors of favourite points no longer being shown :-)

Being a stats-junkie, I can see why this would interest you (and would potentially interest me as well)... ... however, I'm not sure this is as easy as you make it out. I have had some "nemesis" caches that needed half a dozen or more attempts (the record holder is one with 11 visits when I finally found it). I might log no DNF, one DNF or in some cases even more than one DNF on such a cache, but would probably not log a DNF for every attempt (also being a cache owner I appreciate DNF logs but am not sure I would want 12 of them from the same cacher on every attempt). Besides, wouldn't you want to differentiate between caches where you first had a DNF and later a find and those where you had a DNF but haven't been back to find it succesfully? In the end I think this statistic would depend so much on how each cacher logs his DNFs that it would be meaningless for comparisons.

This would be a great feature. If I discover a TB in a cache the decision whether to leave it there (and only discover it) or to take it with me depends greatly on where it has recently been. This information is not currently easily visible and adding this would make the decision a lot easier!

And to expand a bit on my idea: I'm not sure if the commercial TopoMaps for Garmin GPSr use the same gmapsupp.img format or another. If they use the same format, this change would even allow us to use our TopoMaps on the iPhone, which would be a great thing (assuming this is possible (a) with regards to unlocking the maps for the iPhone and ( the licensing terms of the Topo maps).

As for (2), see herefor a similar proposal.

Then how mad will you be when they drop the price to $12 annually (or even less)? Will you expect that to be pro-rated and a refund issued? No, that just means he gets to live twice as long ;-) @Marshall: not being a charter member, your proposal has little impact on me, so I'm not really in a position to support or oppose it, but if Groundspeak would be willing to offer such a package, I would certainly not begrudge it!

Thank you, you phrased that much better than I could have done.

I occasionally go caching abroad where I don't have GSM data connection. I know I can already use offline maps, but think this could be improved. Currently I need to do the following: 1. create a PQ with the caches I'm interested in 2. download the PQ onto my iPhone 3. store the PQ for offline use, select "include maps" Now the last steps works in principle, however, it is very slow as it seems that every tile is downloaded seperately. I've tried it with a 1000 cache PQ before my trip to Berlin and aborted after about 4 hours when it still hadn't progressed past cache 500. I then broke my PQ up into 10 pocket queries of 100 caches each and that worked, but it was a lot of hassle to do so and for larger trips might just not be practical. Also, I'm not sure how this mechanism works and whether it detects if a tile has already been loaded for another cache in the same PQ (I won't even speculate about caches in other PQs in the same area). On the other hand, I can just upload a pre-generated OSM file onto my Garmin device and have the offline maps available easily. Would it be possible to add support for gmapsupp.img type OSM maps to the iPhone app? Ideally I could then transfer such maps when synching my iPhone using iTunes over my USB cable or WLAN and would just need to download the PQs for the cache data, not the maps. This would make this step much less painful. Many sites already offer such maps and the format used should be well documented. This would be a great addition to offline caching with the iPhone app.

I think this has been requested on user voice already. It was a good idea then and still is a good idea now! +3

Add another reason: - because "it's a nice area" (some of those exist even without scenic views)

That would indeed be a great addition! +3

I really like what you have done with the corrected coordinates feature you added in your latest update. I am especially looking forward to your adding this to the API which will then let me show those caches in their correct place on my iPhone App maps. However, I have encountered a snag with the feature: I am also a user of GSAK which has had the "corrected coordinate" feature for a long time. It keeps two separate variables for the original (and optionally) corrected coordinates. It also lets me filter for caches where the two sets of coords differ, letting my quickly see, which caches I have "solved". For testing, I corrected the coordinates on geocaching.com for one of the caches that I have already corrected in GSAK, then I downloaded the "single GPX" file for that cache. It seems that in that GPX you *only* deliver the corrected coordinates instead of the original coordinates. This means that GSAK has no way of determining that these are corrected coordinates and will therefore overwrite its "original coordinate" field with the corrected ones included in your GPX file. After this, such caches will obviously no longer be included in my "corredted coordinate" filter (as both the original and corrected coord fields now contain the corrected coordinates). I realise that this is ultimately not your problem, but in order for GSAK to be able to solve this issue, it will need a way to detect if the coords delivered in the sinlge GPX file (and later on in the PQ and API data) are the original ones or corrected ones. I also realise that you cannot leave the original coordinates in the place they were so far and add the corrected ones in a GPX extension, as that would not work with most GPSr devices. I am therefore suggesting that when you extend the PQ and API to include this information, you add a possibility to somehow indicate the correction. I can imagine various ways of doing this: automatically adding a waypoint containing the original coordinates (with a fixed naming scheme to easily identify this waypoint) as already suggested in this feature request extend the GPX syntax to include the original coordinates (basically the first idea but using a GPX extension instead of an automatic waypoint adding a new attribute called "corrected coordinates" (though that would be a less than ideal solution as the original coords would not be inlcuded) if you can think of any other way, that's fine by me, as long as the information is included Thanks for considering this.

This is great news, thanks for letting us know!

I agree. While I think HTML or BBCode in hints would be nice, I can see why they are not supported. But please fix the bug that linefeeds which are correctly shown while the hint is encrypted, are lost when it is decrypted.