+noncentric Posted February 22, 2017 Share Posted February 22, 2017 I meant displaying all caches at the same time (with one command) without visiting the FP lists of all cachers who have favourited a cache. I don't understand what you're looking for. I haven't read the past topics that cezanne has mentioned, so I'm not sure what has been presented in previous years. A possibly feasible system I could imagine is something like: -- When PM's favorite a cache, then they'd also select from a list of reasons that they favorited it. Maybe there are 100 caches favorited for 'clever container' and 50 caches favorited for 'nice view'. Cachers that like finding caches with nice views could then search for caches that were favorited with the 'nice view' reason. -- This would return the 50 caches, potentially ranked by how many times they were favorited because of 'nice view'. One cache might've been favorited as 'nice view' by 30 cachers, while another cache by only 2 cachers. -- But maybe the latter cache is at a more isolated location and only had 2 finds, so the ranking would need to be based on percentage, but only on the percentage of PM's that favorited the cache after the "reasons" system was created. -- And then, there could be a cache favorited for multiple reasons - a clever container with a nice view. Yikes, a lot of work involved in creating such a system to store and process the related data. Another system that I don't think is feasible within the geocaching.com platform is something like the 'recommendation systems' employed by Amazon or Netflix. Recommendation algorithms look at what products someone likes and then recommends other products that are similar and/or recommends other products that similar people have liked. It may not be apparent to everyone that such systems are very complex and rely on a great deal of both data and time. They are rarely accurate at the outset. -- Both the users (cachers) and the products (caches) have to be categorized and clustered into similar groups. -- Since BM's cannot like (favorite) caches, then the recommendation system cannot factor them into the algorithm and that leaves a large gap. Since caches aren't flagged as film cans vs Lock-n-Lock's, then the algorihtm can't cluster caches together based on the 'quality' of their containers, only on their listed size/type/D/T. -- They require a lot of data and they need time to refine. If the algorithm recommends PRODUCT-A to USER-1 and USER-1 buys/watches/finds PRODUCT-A, then the algorithm can learn by whether USER-1 likes/favorites PRODUCT-A later on. If USER-1 doesn't end up favoriting PRODUCT-A, then the algorithm might interpret that as a missed recommendation when it's just because USER-1 didn't have anymore favorite points left to give. That's my flawed attempt at explaining a complex process. There are plenty of articles/discussions on the web about recommendation algorithms and what they involve. Quote Link to comment
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.