Jump to content

Valentijn77

+Premium Members
  • Posts

    59
  • Joined

  • Last visited

Posts posted by Valentijn77

  1. Hi,

     

    Would it be an option to make the "Don't show again" checkbox a setting on the user profile?

    That would mean users only have to set it once and forget about it.

    The current popup keeps popping up on new devices, but also the "don't show again" checkbox doesn't work for everyone,

    See 

    Relying on cookies might be or appears to be not 100% reliable.

     

    Valentijn

     

    • Helpful 2
  2. As mentioned in the (closed) topic 

    The external link warning "Don't show again" checkbox doesn't work.  Even after choosing that, the popup keeps coming up.

    On all links it seems, also on those that are supposed to be accepted like geocheck.

    Cookies are enabled, I have like 20 or 30 cookies on geocaching.com. I hope they don't exceed the maximum size of the cookie header causing some of them to be ignored....

    • Helpful 1
  3. [...] something like an indicator could be added, or a different icong which will show all caches underneath when hovering over it. This might be more difficult to implement.

     

    When there are more than one caches at the same place and you're clicking the icon, then there actually are prev/next buttons to the prev/next (sic!) caches.

     

    0edc55c31e17523d2fef68050ffdfa52.png

     

    And there is hovering as well:

     

    bdbd646c3d71b7f081f7261262ea0224.png

     

    Hans

    Wow, can't believe I never saw this. The hovering seems to be not always working, so it's still not perfect but good to know!

  4. I hope GS will solve this one day as in the netherlands the cache density is very high.

    There's a general problem of dense caches overlapping, and while I'd like to see that solved, I can't think of a good solution myself, so I can't fault GS for not finding one.

     

    This case, however, is a cache with corrected coordinates. I think it would make sense to give such caches "priority" and show them in front of any other caches.

     

    Corrected coordinates should result in the cache being displayed in those new/corrected coordinates instead of the old coordinates.

    If there are overlaps, something like an indicator could be added, or a different icong which will show all caches underneath when hovering over it. This might be more difficult to implement.

  5. Density -- wow, no kidding. Is there really a 161m separation between the final of that multi and the traditional? Can't really tell the map scale from here.

    As long as the physical points are 161m apart, the virtual points can be in the exact same spot.

    There are lots of examples around here where caches are very close like this, some even in the exact same coordinate because COs thinks that's cool.

  6. Hi,

     

    I have modified the coordinates for a Multicache: https://www.geocaching.com/geocache/GC1NPPC_de-molenheide?guid=ba2047f2-1359-4fa5-946e-6748921c3e9e

     

    On the cache page itself everything displays normal, cache is visible in the map view on the cache page.

     

    http://imgur.com/a/nQuMT

     

    But on the global geocaching map (Play->View geocaching map: https://www.geocaching.com/map/) the cache has dissappeared.

    It's not showing at the original coordinates, nor the corrected ones.

     

    http://imgur.com/a/JLH3f

     

    Already tried zooming in and out, but no luck.

     

    Google Chrome on Windows, using google maps.

     

    Valentijn77

  7. Hi,

     

    Current situation:

    When creating a notification rule, you can only have one cachetype in each rule.

    So if you want to be notified for all cahe-types in a certain area, you need to setup 19 (!) notification rules.

    If you have 4 or 5 areas for which you want notifications, you need to setup (and maintain almost one hundred rules).

     

    2016_08_03_10_59_51_Mail.png

     

    Suggested improvement:

    Add a "All cachetypes" option to the drawdown. This way you can setup 1 notification rule to be alerted on all cache types.

     

    Thanks,

     

    Opper

  8. OK let me explain the reason behind my prior questions.

    A while back I downloaded all caches for an area and saved them in GSAK. I followed it up with weekly pocket query just for caches placed during the last week and added them to GSAK. Now I discovered new caches in that area that my system had missed!

    After some investigations I do now understand what has happened. The system can look at published caches only. But a cache published during the last week that has a hidden date older than a week will be missed! And that is was happened!

    It can get confusing if the time from 'Hidden' to 'Published' is long, ie if you get a new cache notification, you look at it and it is 'a month old' !

    Personally I would prefer the PQ filter to be using the published date, but it is what it is!

    Same here. What we need is a "Published during last week/month" filter. I doubt it's going to happen, but I am in favour!

  9. Definitely a must have feature. My personal opinion is that it should have been there from the start?

    What use is the map if the caches are shown in the wrong/old location?

     

    It's quite frustrating that simple things like this aren't included in the gc.com maps functionality.

     

    EDIT: Looks like a lot people are experiencing this issues and are hoping for a fix:

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=316519&st=0&p=5310533

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=316568&st=0&p=5310934

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=300151&st=100&p=5108446

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=317505&st=0&p=5323228

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=317375&st=0&p=5328752

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=317375&st=0&p=5328752

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=320995&st=0&p=5366131

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=320995&st=0&p=5366131

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=303353&st=0&p=5397905

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=324247&st=0&p=5404159

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=312126&st=0&p=5262815

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=313330&st=0&p=5277154

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=312509&st=0&p=5286818

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=314785&st=0&p=5290633

     

    http://forums.Groundspeak.com/GC/index.php?showtopic=314310&st=0&p=5295345

  10. The tip was to load the PQ into GSAK and then use the getfavorite macro.

    As I am saying after that it's easier to use the API to get the caches, including favorites points.

    You are however limited to the limits of the API (few requests allowed).

    FYI, you can download or refresh 6000 caches per 24 hour period using the API. How many caches are in the area you're wanting to filter?

     

    And if the filter were done when constructing the query, instead downloading 6000 caches and filtering after the fact, filtering when the query is made would reduce (and probably significantly) the size of the download.

     

    Since, as you've shown, the API does support filtering, why doesn't backend code which processes the form elements just use the API? Then it's just a matter of adding the form element for specifying the minimum value for favorite points.

    The GC ecosystem has been growing over the years and it looks like it consists of multiple components working together, some newer, some older. Possibly a service oriented architectue. This is visible for example with the pocket query integration with maps.

    You can view the list of pocket queries and select a query to be displayed. But if you want to edit a query you have to go back to the website, find the query again and edit it.

  11. It's only the first part that would require changing, and if the API supported filtering by favorite points, most of the work would be done. What is being asked for is a filter. If I enter into the PQ form that I only want to see caches with 50 or more favorite points I don't need to know that one cache has 51 favorites and another has 70. All I am asking for is a list of caches which have at least 50 favorite points. If I'm seeing too many I just increase the 50 to 70 (or whatever).

    Exactly just make the favorite points field a first class citizen by allowing filtering.

    I know this might affect multiple layers in the system, but still it would a big plus if you could just go online en do a quick search and filter to find popular caches.

    No need to do any manual exporting importing filtering sorting macroing in 1 or more external tools.

  12. Just tried GSAK and it shows that the favorite field is not a primary field in the api.

    It's not included in the PQ export, so GSAK has to perform ONE THOUSAND api calls just to get the favorite field populated.

     

    I am not sure this is only caused by the PQ Export lacking the favorites field, or that the same problem occurs when perform queries against the API.

     

    EDIT: And it doesn't work correctly. It says there are only 2 caches with >100 points, where in reality there are 30+ caches.

    Actually, you can retrieve data for 30 caches in one API call, so you should be able to get all the favorite points for 1000 caches in 34 API calls. One is limited to 30 API calls per minute, so to update 1000 caches will take just over a minute to perform.

    Ok, in that case GSAK or the macro could be improved :)

    Actually, I think you just need to learn how to use GSAK and the macro. They work just fine. If you have questions about how to use them, then check out the GSAK forum.

    This by itself indicates that its too difficult to retrieve the top favorited caches in a certain area :-)

     

    Using the macro is just pressing run and observing its doing 1000 api calls, not much too learn there.

     

    Not using PQ is better, because via API you get the favorite points automagically.

  13. You are looking at the wrong end of the pipeline. GS sets the limits for the API and GSAK has to work within the constraints given.

    I know, but since GS isn't to active reacting to feature requests and such, the only hope I have is that GSAK or the macro can be changed.

    I might take a look myself at the macro.

     

    If only GS went open source with their platform and work together with the community on improving it.

  14. Just tried GSAK and it shows that the favorite field is not a primary field in the api.

    It's not included in the PQ export, so GSAK has to perform ONE THOUSAND api calls just to get the favorite field populated.

     

    I am not sure this is only caused by the PQ Export lacking the favorites field, or that the same problem occurs when perform queries against the API.

     

    EDIT: And it doesn't work correctly. It says there are only 2 caches with >100 points, where in reality there are 30+ caches.

    Actually, you can retrieve data for 30 caches in one API call, so you should be able to get all the favorite points for 1000 caches in 34 API calls. One is limited to 30 API calls per minute, so to update 1000 caches will take just over a minute to perform.

    Ok, in that case GSAK or the macro could be improved :)

  15. Get GSAK. Load the PQ. Run the Favorites macro to fill the favorites field then filter for the top 10 percent and sent it to Basecamp. Easy.

    Thanks for the tip to GSAK.

    Still I'd like to see this in the geocaching.com site.

    Would be way easier than to install 3rd party tools and go exporting/importing list of caches.

    GSAK only works on Windows BTW.

     

    Just tried GSAK and it shows that the favorite field is not a primary field in the api.

    It's not included in the PQ export, so GSAK has to perform ONE THOUSAND api calls just to get the favorite field populated.

     

    I am not sure this is only caused by the PQ Export lacking the favorites field, or that the same problem occurs when perform queries against the API.

     

    EDIT: And it doesn't work correctly. It says there are only 2 caches with >100 points, where in reality there are 30+ caches.

  16. Hello,

     

    Often when watching a bookmark list, I am wondering where the caches are on the map.

     

    A "Map this bookmark list" option (just ad when searching for caches in a specific location) would be ideal for this.

     

    If a direct link to the map is difficult or unwanted, maybe a "Preview" functions as with pocket queries could be helpful?

    From that screen you could click "Map this Location" or similar?

     

    Let me know your thoughts,

     

    Opper.

    You can make it a PQ with one click and get what you want.

    yeah now I've found the feature for PQ, it's quite easy.

×
×
  • Create New...