- Popular Post
sbeelis
-
Posts
38 -
Joined
-
Last visited
Posts posted by sbeelis
-
-
6 minutes ago, technetium said:
Moving from complaining to working to a solution: Would it be possible to allow some attributes that allow a bit of javascript code under control of GCHQ to hide and show elements in a profile page?
I asked the same question a few posts upthread and bootron's response was crystal clear: there are no plans of doing that.
-
.png)
2
-
-
13 minutes ago, bootron said:
We do not have any plans to open up the ability to use a subset of javascript at this time.
Thanks for your reply (even if it is not what I had hoped for).
-
1
-
-
2 minutes ago, bootron said:
The most widely-used third party providers were given several weeks of notice.
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....
-
.png)
1
-
3
-
-
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...
-
6
-
-
Quote
- In your mind, what is a high quality geocache?
As a precondition for a cache to be a high quality cache, it needs to be properly maintained (dry, signable log)
I see three criteria to a cache:
- the location
- the container
- the story/listing/puzzle (for mystery caches)
A good cache is a cache where at least one of the three criteria stands out positively and none of them is really bad
A great cache is a cache where all three criteria stand out positively
Another quality criteria is to hide the largest possible box that fits the location (why hide a preform in the woods if there is room for an ammo can)? There are places where a nano is the only choice to hide (but then the location and/or story better be outstanding) but if possible, go for larger containers.
Quote- In your mind, what is a low quality geocache?
A cache where one of the above three criteria stands out in a negative way:
- locations that are filthy, disgusting or overly exposed in inappropriate locations
- containers that are leaky, not durable
- thoughtless listings or listings that are incomprehensible
Any unmaintained cache is a low quality cache.
Quote- What steps can the community take to improve geocache quality?
Finders:
- be honest in your logs. If you didn't like the cache, tell the owner (and other finders)
- log DNFs if you did not find the cache
- log NM if the cache is in bad condition
- log NA if the cache should not be where it is due to safety or other concerns
- DO NOT PLACE THROWDOWNS and take the DNF with pride
Owners:
- maintain your caches well, regularly and quickly
- put some effort into hiding a cache and think about the hide before you hide it
- hide the largest possible container that fits the location
Quote- What steps can Geocaching HQ take to improve geocache quality?
-
in addition to Favourite Points also give us 1 "Sticker of Shame" for every 10 finds so we can downvote low quality caches
This could then be taken into account when calculating the health score - make it clearer that throw downs are not acceptable
-
make hiding a privilege (say X hides per year and then another hide for each Y favorite points earned on existing hides), deduct hiding points for badly maintained caches (though identifying them might be tough, if the sticker of shame is introduced, these can be deducted from the favourites when granting additional hides).
This would curb the high volume hiders that do not maintain their caches
Maybe restrict hiding to premium members to stop people from creating dozens of sock puppets to get around the hiding limit
-
6
-
2
-
1
-
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!
-
I still say get rid of the guideline completely if it's not going to be adhered to. What is the point of having the guideline if it's absolutely meaningless?
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
-
This feature will be going away shortly. We are instead focusing resources on a better solution, which is allowing users to "correct" coordinates for puzzle and multicaches and have those coordinates delivered in their "normal" PQs instead.
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.
-
However, you are aware that offline street maps are currently possible in the app, correct? You simply need to select OpenStreetMap for your street map provider and then save for offline use.
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 :-)
-
I cannot find this statistic option available on the website or through a third party option, nor can I find it as a suggestion (although hard to define terms to search for)
A statistic for "Found/Searched".
I worked mine out by counting the smiley and sad faces in my personal "Your Geocaching Details" page.
Being a stats-junkie, I can see why this would interest you (and would potentially interest me as well)...
Smiley + sad = Total searches.... 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.
-
1) Offer a "Lifetime Membership" to Charter Members only for a onetime fee.
(say $250.00 +/- We would not have to remember to renew year after year and not be subject to future increases in membership fees)
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!
-
A cache in a quiet rose garden that is open to the public may not have a "scenic view", but it is certainly in "a nice area". A cache in a cathedral grove in a redwood forest may not have a "scenic view" either, but it is certainly in "a nice area".
If you're expecting the "scenic view" category to include such locations, then I recommend choosing a different phrase to describe the category. For some of us, the phrase "scenic view" implies that you can see something in the distance; it doesn't really apply to something that is close, especially when the things that are close obscure your view of anything distant.
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.
- 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
-
This is great news, thanks for letting us know!
.png)
.png)
the licensing terms of the Topo maps).
Import Adventure Labs into GSAK using the "Import Adventure Labs" macro
in Playing Adventures
Posted
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.
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.
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.