+frinklabs Posted June 25, 2014 Share Posted June 25, 2014 This request is precipitated by discussions around losing one's completed grid when a cache's D/T rating is changed: http://forums.Groundspeak.com/GC/index.php?showtopic=323560 If there's a "snapshot" at log time of what was the cache's D/T rating, this becomes a non-issue. Quote Link to comment
Pup Patrol Posted June 25, 2014 Share Posted June 25, 2014 (edited) I like this idea. We had the opposite of most people...a cache we found that was probably only a 1/1.5 when we found it originally has been moved and the Terrain upped to 2.0/4.0. I just don't agree with the new D/T rating, and sure don't feel like we "earned" it. B. (dreams of ever completing any type of grid...) Edited June 25, 2014 by Pup Patrol Quote Link to comment
team tisri Posted June 25, 2014 Share Posted June 25, 2014 This request is precipitated by discussions around losing one's completed grid when a cache's D/T rating is changed: http://forums.Groundspeak.com/GC/index.php?showtopic=323560 If there's a "snapshot" at log time of what was the cache's D/T rating, this becomes a non-issue. Just makes it easier to cheat at the incidental side games. Quote Link to comment
+frinklabs Posted June 25, 2014 Author Share Posted June 25, 2014 This request is precipitated by discussions around losing one's completed grid when a cache's D/T rating is changed: http://forums.Groundspeak.com/GC/index.php?showtopic=323560 If there's a "snapshot" at log time of what was the cache's D/T rating, this becomes a non-issue. Just makes it easier to cheat at the incidental side games. Are you suggesting that the current implementation makes it harder to cheat at the incidental side games? Quote Link to comment
Pup Patrol Posted June 25, 2014 Share Posted June 25, 2014 (edited) Just makes it easier to cheat at the incidental side games. I don't understand the concept of "cheating" in this non-competitive hobby. There's no cash prize to be won, no trophies to be awarded, so "cheating" would be rather pointless. I fail to see how frinklab's suggestion would be any more conducive to this alleged "cheating" than the current system. B. Edited June 26, 2014 by Pup Patrol Quote Link to comment
+dprovan Posted June 26, 2014 Share Posted June 26, 2014 This request is precipitated by discussions around losing one's completed grid when a cache's D/T rating is changed: http://forums.Groundspeak.com/GC/index.php?showtopic=323560 If there's a "snapshot" at log time of what was the cache's D/T rating, this becomes a non-issue. No, it wouldn't change anything. The owner of a grid challenge doesn't have to accept historical ratings, even if they're listed in the logs. Quote Link to comment
cezanne Posted June 26, 2014 Share Posted June 26, 2014 (edited) This request is precipitated by discussions around losing one's completed grid when a cache's D/T rating is changed: http://forums.Groundspeak.com/GC/index.php?showtopic=323560 If there's a "snapshot" at log time of what was the cache's D/T rating, this becomes a non-issue. No, it wouldn't change anything. The owner of a grid challenge doesn't have to accept historical ratings, even if they're listed in the logs. In any case it would/could have an effect on the grids that are shown on diverse stats and badge system sites. And it also would help a great deal to allow to add additional hints to a difficult puzzle cache after a while and decreasing the D-rating accordingly wthout annoying those who found the cache without those hints. Cezanne Edited June 26, 2014 by cezanne Quote Link to comment
+niraD Posted June 26, 2014 Share Posted June 26, 2014 FWIW, I've seen logs that included a sting of characters at the end, where this string of characters encoded information on the state of the cache at the time the finder found it: size, difficulty and terrain ratings, finder's impression of what the difficulty and terrain ratings should have been, subtype (e.g., challenge vs puzzle vs night cache). The finder uses some stats package to process these strings, to produce stats that fit his specific preferences. Quote Link to comment
+Corfman Clan Posted June 26, 2014 Share Posted June 26, 2014 This request is precipitated by discussions around losing one's completed grid when a cache's D/T rating is changed: http://forums.Groundspeak.com/GC/index.php?showtopic=323560 If there's a "snapshot" at log time of what was the cache's D/T rating, this becomes a non-issue. No, it wouldn't change anything. The owner of a grid challenge doesn't have to accept historical ratings, even if they're listed in the logs. In addition, most of those modeled after the original Well Rounded Cacher Challenge, disallow including caches that have had their D/T ratings changed. Though a problem with that is that there is no reasonable way to know if a cache's D/T rating has changed. The OP would help with this, but I imagine the application for the request is extremely limited and probably not worth the effort. Quote Link to comment
team tisri Posted June 26, 2014 Share Posted June 26, 2014 This request is precipitated by discussions around losing one's completed grid when a cache's D/T rating is changed: http://forums.Groundspeak.com/GC/index.php?showtopic=323560 If there's a "snapshot" at log time of what was the cache's D/T rating, this becomes a non-issue. Just makes it easier to cheat at the incidental side games. Are you suggesting that the current implementation makes it harder to cheat at the incidental side games? Yes, because with the new system you could create a sock account, publish a couple of caches, change the D/T ratings while repeatedly finding them, and so fill up your D/T grid with historical finds of a single cache. Quote Link to comment
team tisri Posted June 26, 2014 Share Posted June 26, 2014 Just makes it easier to cheat at the incidental side games. I don't understand the concept of "cheating" in this non-competitive hobby. There's no cash prize to be won, no trophies to be awarded, so "cheating" would be rather pointless. I fail to see how frinklab's suggestion would be any more conducive to this alleged "cheating" than the current system. B. Looking at the threads about people who claim finds when they didn't actually find it, presumably enough people do cheat for it to be considered an issue. I don't see how the suggestion offers a useful benefit - it seems like a redesign of the system just for the sake of a side game. If the log is to show the D/T at the time of finding then would the stats also need to be calculated based on the log rather than the cache? Honestly, Groundspeak seem so good at breaking things with their releases I shudder to think of the consequences of changing the table containing cache logs. Quote Link to comment
+frinklabs Posted June 27, 2014 Author Share Posted June 27, 2014 If we were to restrict features because they allegedly make it easier to cheat (as if you couldn't already), then there should not be a feature to alter a cache's coordinates. This makes it easier to cheat the saturation guideline and should be removed. Meanwhile, it might be enough to know if and when the D/T has been altered. I still await a response to this, in the other thread: Here's a question for a forum-active reviewer: Can you see history of changes to a cache listing? If so, does that history include changes to the D/T? If so, are they date stamped? I agree with this: Honestly, Groundspeak seem so good at breaking things with their releases I shudder to think of the consequences of changing the table containing cache logs. I don't actually expect them to make any of the changes suggested here; based on my experience thus far, mostly this is the /dev/null of suggestion boxes. Even sensible, well-supported, useful features are ignored, like the one for managing ghost trackables. Quote Link to comment
+2-hobbits Posted March 13, 2016 Share Posted March 13, 2016 I like the idea of freezing D/T as well as country and flag on the date of a find. If it changes afterword it's effect on grid completion, challenges, etc. should be null. If someone wants to cheat by creatimg a dummy account, creating a cache, finding it, changing the D/T and finding again, who cares. They are only cheating themselves. Even the owner of a challenge who knows someone is cheating should only laugh at someone's ability to cheat themselves. As far as country and flag, I mention it to see if there is support for freezing similarly to date of a find, and clearing up amiguities such as St.Martin / Sint Maarten, and the other 'nations' that comprised Netherlands Antilles. In the dynamics of an ever changing political world, and human ability to war incessantly, countries and territories will continue to evolve and political boundaries will change. Quote Link to comment
+NYPaddleCacher Posted March 13, 2016 Share Posted March 13, 2016 I like the idea of freezing D/T as well as country and flag on the date of a find. If it changes afterword it's effect on grid completion, challenges, etc. should be null. If someone wants to cheat by creatimg a dummy account, creating a cache, finding it, changing the D/T and finding again, who cares. They are only cheating themselves. Even the owner of a challenge who knows someone is cheating should only laugh at someone's ability to cheat themselves. As far as country and flag, I mention it to see if there is support for freezing similarly to date of a find, and clearing up amiguities such as St.Martin / Sint Maarten, and the other 'nations' that comprised Netherlands Antilles. In the dynamics of an ever changing political world, and human ability to war incessantly, countries and territories will continue to evolve and political boundaries will change. I think there's zero chance that D/T ratings or country ID for a cache will ever be frozen. I do however agree that the ambiguities with St. Martin/Sint Maarten is worth fixing considering the number of geocaches that are actually impacted. Remember when South Sudan split off from Sudan? GS added South Sudan as an "official" country right after the change went into effect. Of course, at the time I don't believe that there were any caches in the region that is now South Sudan and there may have been only 1 in all of Sudan (prior to the split). Fixing the St.Martin/Sint Maartan issue would be relatively easy. We're only talking about 35 caches or so. Imagine what would they would have to deal with if that vote for Scotland to split from the UK that was done a couple of years ago had passed. Quote Link to comment
+digimuzik Posted March 25, 2016 Share Posted March 25, 2016 FWIW, this doesn't have to be implemented in the massive storage cost method most people seem to think it would be (via storing the D/T with logs). Instead, the cache record itself could store a history of D/T ratings (or heck, a history of previous revisions of the whole cache: description, coords, everything). Then queries for a user's D/T statistics only need to take one extra hop to get data "as of" their find date. As a software developer, this seems like a fun problem to solve. Alas, I am not employed by GZ. Quote Link to comment
+EngPhil Posted March 25, 2016 Share Posted March 25, 2016 FWIW, this doesn't have to be implemented in the massive storage cost method most people seem to think it would be (via storing the D/T with logs). I'd hardly consider it a massive storage cost. Assuming you took one byte each for D and T (though theoretically one byte is enough to store both, if you want to be stingy), with the number of logs currently in the database it adds up to just on 1Gb of extra data -- a rounding error when you consider the storage required for the log text itself. The cost would be in implementation, as well as providing meaningful API methods to access the information, not so much in storage. And processing would be a whole lot easier than with your proposed method, too. Quote Link to comment
+digimuzik Posted March 26, 2016 Share Posted March 26, 2016 Just proposing an alternative I hadn't seen suggested. Creating a historical view of a cache would reap many other benefits as well. As a a dev in the health care industry, this is standard practice, and I'm a little surprised something like this doesn't already exist in some form. In any case, it's just an idea in line with this request. There are, of course, pros and cons to any solution for this. Quote Link to comment
+Walts Hunting Posted March 27, 2016 Share Posted March 27, 2016 FWIW, this doesn't have to be implemented in the massive storage cost method most people seem to think it would be (via storing the D/T with logs). Instead, the cache record itself could store a history of D/T ratings (or heck, a history of previous revisions of the whole cache: description, coords, everything). Then queries for a user's D/T statistics only need to take one extra hop to get data "as of" their find date. As a software developer, this seems like a fun problem to solve. Alas, I am not employed by GZ. So a heavy user would hit that extra hop 62,000 times a day and that wouldn't load the system. Quote Link to comment
+frinklabs Posted March 27, 2016 Author Share Posted March 27, 2016 FWIW, this doesn't have to be implemented in the massive storage cost method most people seem to think it would be (via storing the D/T with logs). Instead, the cache record itself could store a history of D/T ratings (or heck, a history of previous revisions of the whole cache: description, coords, everything). Then queries for a user's D/T statistics only need to take one extra hop to get data "as of" their find date. As a software developer, this seems like a fun problem to solve. Alas, I am not employed by GZ. So a heavy user would hit that extra hop 62,000 times a day and that wouldn't load the system. Correct. I cannot see the difference between the current query that constructs the Date Found calendar and one which would make the D/T matrix (if the D/T was included in the GL log type, like the found date is now). Quote Link to comment
+digimuzik Posted March 28, 2016 Share Posted March 28, 2016 Yeesh. I didn't realize this was where pro database designers criticized helpful suggestions (actually, I realize it wasn't even original; frinklabs asked essentially the same thing in June 2014). It's an alternative solution that reaps other useful benefits besides helping 'incidental side games' (of which, I'm obviously not a serious contender). If GS reads these, then the idea is planted, and the implementers can debate the merits. If this forum is really a black hole, then there's not much point in arguing. Not saying others aren't more than welcome to keep trashing my idea. I just won't defend it any more, since I'm not even married to it myself and have pretty much no say in how this could get implemented anyway. I'll go try to contribute somewhere else and see if I'm welcomed there... Quote Link to comment
+NYPaddleCacher Posted March 28, 2016 Share Posted March 28, 2016 Yeesh. I didn't realize this was where pro database designers criticized helpful suggestions (actually, I realize it wasn't even original; frinklabs asked essentially the same thing in June 2014). It's an alternative solution that reaps other useful benefits besides helping 'incidental side games' (of which, I'm obviously not a serious contender). If GS reads these, then the idea is planted, and the implementers can debate the merits. If this forum is really a black hole, then there's not much point in arguing. Not saying others aren't more than welcome to keep trashing my idea. I just won't defend it any more, since I'm not even married to it myself and have pretty much no say in how this could get implemented anyway. I'll go try to contribute somewhere else and see if I'm welcomed there... I didn't see anything unwelcoming in the responses you got to your suggestion. As a software developer and systems architect myself (for over 30 years) I always welcome different implementation ideas but at the end of the day this is a "bugs and features discussion" forum, thus we're to going to talk about the benefits vs. cost of any feature under discussion. Those that are implementing features at GS often don't participate in discussions but they're the only ones that have access to the code. All we can do i speculate about the advantages or disadvantages for any implementation strategy. Quote Link to comment
+frinklabs Posted March 28, 2016 Author Share Posted March 28, 2016 at the end of the day this is a "bugs and features discussion" forum Based on this grouping, I think it would be fair to say that they consider a "feature suggestion" to be just as problematic as a "bug" However, when it comes to bugs their response is almost always admirably prompt and efficient. Maybe there should be two forums -- one for bug reports that they can monitor, and one for feature suggestions which can be ignored? Those that are implementing features at GS often don't participate in discussions I was going back through suggestion threads to try and find an example of relevant participation in a new feature discussion (which doesn't include indications that there is "no commitment to put it on the schedule to develop" or "currently in the brainstorming phase"). The most recent post I could find was from more than four years ago, and isn't even really about the feature itself. Quote Link to comment
+The A-Team Posted March 29, 2016 Share Posted March 29, 2016 Maybe there should be two forums -- one for bug reports that they can monitor, and one for feature suggestions which can be ignored? There used to be separate forums for feature requests and bug reports, but a year or two ago someone at HQ decided to lump them together into one forum. Quote Link to comment
+FamilieFrohne Posted March 31, 2016 Share Posted March 31, 2016 (edited) Back to topic: Why not simply freeze the D-T-rating and attributes of the cache listing (so the cache owner can't change it) when the first found log is written? Changes to these values would be a job for a reviewer / operator / whoever then. This way you can be sure, your D-T-grid does not change so easily. Edited March 31, 2016 by FamilieFrohne Quote Link to comment
+niraD Posted March 31, 2016 Share Posted March 31, 2016 Back to topic: Why not simply freeze the D-T-rating and attributes of the cache listing (so the cache owner can't change it) when the first found log is written? Changes to these values would be a job for a reviewer / operator / whoever then. This way you can be sure, your D-T-grid does not change so easily.Because the point of the difficulty/terrain ratings is not to preserve your precious D/T grid. The point of the difficulty/terrain ratings is to communicate the general nature of the geocaching experience to potential seekers, so they can better assess whether they should attempt to find the cache. When the situation changes (or if the CO merely decides that the previous ratings were inaccurate), then it is better for the CO to update the ratings promptly, without additional barriers to completing the update. That way, potential seekers have more accurate information more quickly, instead of being forced to use known inaccurate information. Quote Link to comment
+FamilieFrohne Posted March 31, 2016 Share Posted March 31, 2016 Because the point of the difficulty/terrain ratings is not to preserve your precious D/T grid. The point of the difficulty/terrain ratings is to communicate the general nature of the geocaching experience to potential seekers, so they can better assess whether they should attempt to find the cache. When the situation changes (or if the CO merely decides that the previous ratings were inaccurate), then it is better for the CO to update the ratings promptly, without additional barriers to completing the update. That way, potential seekers have more accurate information more quickly, instead of being forced to use known inaccurate information. Thats something I didn't think about. Thanks for reminding me. Quote Link to comment
+frinklabs Posted January 5, 2017 Author Share Posted January 5, 2017 Below is a post in the Changing a date on a historic cache (GC2DBE) thread. Bumping this thread to suggest an enhancement to the feature that could snapshot all the cache's data at the time the log is posted, not just D/T These incidences can also be precipitated by a change to the difficulty or terrain. Here were two suggestions that might have mitigated that: [FEATURE] Altering D/T as a log type [FEATURE] Include D/T rating in Found It log Should I bother suggesting these? [FEATURE] Altering placed date as a log type [FEATURE] Include temporal cache data snapshot in Found It log (the latter could also include other alterable things like Attributes) Quote Link to comment
+thebruce0 Posted January 5, 2017 Share Posted January 5, 2017 (edited) I'd considered that long ago as well, but ouch the amount of data to snapshot with each and every log would be unthinkable. The alternative I posted somewhere was to keep a changelog when properties of a cache are updated. If the Difficulty is only changed once 3 years after publish and it gets another 2 years of life before archival, it's easy for the system to determine that Find logs posted pre-change used the first D, and those after used the updated D. No need to snapshot duplicate data for every log. I do find value in this feature, because currently stats only display current cache properties, not necessarily the statistics of your caching career based on your actual previous accomplishments. Having them as a more accurate historical account would help the user statistics actually be more like what they're intended to display. For arguments' sake, if I were only ever finding water caches because I love canoes, I might only ever target 5T caches. Later a CO decides their series is no longer 5T because the water level has lowered, and the stats are now skewed to easy walks. The career stats are inaccurate. Having the snapshot means stats can still show the user found them when they were actually 5T's. Of course the suggestion being this thread isn't perfect - no feature is - but it's not really that hard a module to develop, it's a transparent self-contained back-end add-on to the site under cache listing editing, and the hardest part would be integrating the new change log data with stats generation. That's about it the way I see it as a non-GS web app developer. ETA: An extra excessive bonus could be to allow the finder for their find log on a cache to select either the cache stats as of the Log date or the current cache stats - in case the update(s) was to fix a legitimate error. So the default would be stats as of the log date, but w/an option to use current cache stats. Edited January 5, 2017 by thebruce0 Quote Link to comment
+niraD Posted January 6, 2017 Share Posted January 6, 2017 I'd considered that long ago as well, but ouch the amount of data to snapshot with each and every log would be unthinkable.It doesn't have to be an unthinkable amount of data for each and every log. Every time the cache data changes (which should be relatively rare), the system could snapshot the data, and create a checksum identifying the snapshot. Then each log just needs to save the checksum of the then-current cache data. Quote Link to comment
+thebruce0 Posted January 6, 2017 Share Posted January 6, 2017 (edited) I'd considered that long ago as well, but ouch the amount of data to snapshot with each and every log would be unthinkable.It doesn't have to be an unthinkable amount of data for each and every log. Every time the cache data changes (which should be relatively rare), the system could snapshot the data, and create a checksum identifying the snapshot. Then each log just needs to save the checksum of the then-current cache data. Ok bad wording on my part; I didn't mean unthinkable amount of data per log, but rather that there's a vastly higher rate of logs posted than listings edited, so storing information that would for the most part be duplicate for every log seems way overboard, when all that's needed is data from the other perspective: The relevant data is tied to the listing, not the log. The log's only interest is the lookup date, so snapshot the cache data before the edits are saved and store with the edit date. No need to store the cache information (or checksum of such, or any extra data, even) per log when on that side of the line it's all just duplicate info until the next edit; it already has the lookup info needed: log date. Minimal additional data storage. ie, an inordinate amount of extra duplicate data would be stored if every log contained a snapshot in some form of the cache's data, when all that's needed is a single snapshot per edit. Or, alternatively, to help avoid numerous quick-saves when a CO may edit until they're satisfied, only store the cache data as of the beginning of the current date. Skip the timestamp, just reference the GMT (+00:00) datestamp. Just playing off a concept of a simple changelog. Edited January 6, 2017 by thebruce0 Quote Link to comment
+dprovan Posted January 6, 2017 Share Posted January 6, 2017 If the rating was wrong and then corrected, what's the logic behind maintaining the erroneous rating? Sure, sometimes ratings are changed to reflect a real change, but often they are changed because they have just always been inaccurate. Quote Link to comment
+thebruce0 Posted January 6, 2017 Share Posted January 6, 2017 If the rating was wrong and then corrected, what's the logic behind maintaining the erroneous rating? Sure, sometimes ratings are changed to reflect a real change, but often they are changed because they have just always been inaccurate. Of course the suggestion being this thread isn't perfect - no feature is Problem: Occasional legit mistakes being corrected may be snapshotted. Partial mitigation: Day-edited single snapshot; Log option to lookup cache stat by log date or use current listing stats; Perhaps allow the CO to mark legitimate edit snapshots? Does the benefit of the feature as a whole being developed for the community outweigh any potential problem(s) and preventative measures? *shrug* that's the subjective question As a CO, knowing people may be needing certain stats, if I change something the cache listing I make sure to include a note with the date of the change and what was changed - this was more relevant before automated statistic checking was required, for any challenge owner to decide whether a qualifying user can use my edited cache or not (or verify prior qualifications that no longer qualify) - but I generated my own 'change log' for the record, being considerate of challenge cachers. If that 'system' is immitated and automated with cache edits on the server end, I see it being more beneficial than not; but that's IMO. Quote Link to comment
+NYPaddleCacher Posted January 7, 2017 Share Posted January 7, 2017 ETA: An extra excessive bonus could be to allow the finder for their find log on a cache to select either the cache stats as of the Log date or the current cache stats - in case the update(s) was to fix a legitimate error. So the default would be stats as of the log date, but w/an option to use current cache stats. wayback-machine.geocaching.com Quote Link to comment
+NYPaddleCacher Posted January 7, 2017 Share Posted January 7, 2017 If the rating was wrong and then corrected, what's the logic behind maintaining the erroneous rating? Sure, sometimes ratings are changed to reflect a real change, but often they are changed because they have just always been inaccurate. Of course the suggestion being this thread isn't perfect - no feature is Problem: Occasional legit mistakes being corrected may be snapshotted. Partial mitigation: Day-edited single snapshot; Log option to lookup cache stat by log date or use current listing stats; Perhaps allow the CO to mark legitimate edit snapshots? Or the UI could simply asked the cache owner if the corrected data should be saved or just replaced. Use case 1. A CO creates a cache and inadvertently switches the intended values but doesn't noticed until a month after it's been published. The CO corrects the D/T ratings and indicates that they should replace the original values. Use case 2. A CO creates a cache that that requires climbing down and up a steep ravine and gives it a terrain rating of 3.5. A year later a bridge is built over the ravine so the CO changes the T rating to a 2 but want's to keep the 3.5 rating as it indicates the actual terrain rating prior to the bridge being built. Quote Link to comment
+dprovan Posted January 7, 2017 Share Posted January 7, 2017 Problem: Occasional legit mistakes being corrected may be snapshotted. Partial mitigation: Day-edited single snapshot; Log option to lookup cache stat by log date or use current listing stats; Perhaps allow the CO to mark legitimate edit snapshots? Wow, that seems easy...until you consider that the original problem is that people sometimes discover ratings are not permanent. The proposed solution is to implement an additional feature few people will understand, and then "partially mitigate" the additional problems that feature causes by making the feature more and more complicated. I think a better solution is just to shrug. You're never going to be able to prevent all disappointments, and I see no pressing need to prevent disappointment to begin with. Quote Link to comment
+thebruce0 Posted January 8, 2017 Share Posted January 8, 2017 I think a better solution is just to shrug. You're never going to be able to prevent all disappointments, and I see no pressing need to prevent disappointment to begin with. Well, then I guess there's no need for this thread then! We here in teh forumz like to make suggestions and discuss them when there are ideas put forward, towards solving what even very few people might consider something worth improving. Bugs me when people say "it's not a problem/a big enough problem" and just dismiss any ideas outright. If it holds no water, the thread will either eventually die, or be resurrected slightly when someone else chimes in. Why smother it? Or the UI could simply asked the cache owner if the corrected data should be saved or just replaced. Use case 1. A CO creates a cache and inadvertently switches the intended values but doesn't noticed until a month after it's been published. The CO corrects the D/T ratings and indicates that they should replace the original values. Use case 2. A CO creates a cache that that requires climbing down and up a steep ravine and gives it a terrain rating of 3.5. A year later a bridge is built over the ravine so the CO changes the T rating to a 2 but want's to keep the 3.5 rating as it indicates the actual terrain rating prior to the bridge being built. You mean like, give the log poster options to choose which data snapshot they'd like to keep with the log? Add more UI features for snapshots and dates, and returning to past logs to change which values to use if a cache changes? ... dunno. I like the idea of posting a log, and in most cases by default having it use the current data; or if Iknow this is a qualifier I can tell it to 'remember' the current cache properties for my stats. Then if something changes in the future, I don't have to worry about it. Or if it happens unexpectedly I can go to my stats, find the cache in question where the change occurred, and determine if the cache info at log's date is what I wanted to keep, then tell it to use that. To me that seems more straightforward (one or two options, plus other stuff I'm already doing if something like that happens right now). On the CO side, if it's a mistake, I would think that either having the initial cache info stored when I begin editing, or giving me the option to store the 'new' correct data would be nice and simple. I dunno. Six of one, half a dozen the other. At least there are options I guess my only sticking point is, wherever the data is stored, I don't think storing additional cache information along with every posted Find would be an optimal route, from a data optimization standpoint. The relevant edit data is per cache, and if having a flag for a log for which data to use (by log date or current) then that would be per log. I mean, I think I get you're saying to store every cache edit in a snapshot form, and having each log use a back reference for which data to use, but that irks me as a database dev in this context for how to translate that to a simple user interface. Quote Link to comment
+dprovan Posted January 9, 2017 Share Posted January 9, 2017 I think a better solution is just to shrug. You're never going to be able to prevent all disappointments, and I see no pressing need to prevent disappointment to begin with. Well, then I guess there's no need for this thread then! I appreciate the support, but I think the thread's still needed to make the case to the people proposing the new feature. I mean, I think I get you're saying to store every cache edit in a snapshot form, and having each log use a back reference for which data to use, but that irks me as a database dev in this context for how to translate that to a simple user interface. Exactly. Furthermore, let's keep in mind that almost no one will think of this feature until after the rating's been changed, so it will be virtually pointless to give the user the option unless they are allowed to go back and assert their desire for the snapshot long after they've logged the find. At some point you have to stop trying to "improve" the feature with additional complications and start considering whether the feature is really that interesting now that we've started to understand how much effort it will take. Quote Link to comment
+NYPaddleCacher Posted January 9, 2017 Share Posted January 9, 2017 I think a better solution is just to shrug. You're never going to be able to prevent all disappointments, and I see no pressing need to prevent disappointment to begin with. Well, then I guess there's no need for this thread then! We here in teh forumz like to make suggestions and discuss them when there are ideas put forward, towards solving what even very few people might consider something worth improving. Bugs me when people say "it's not a problem/a big enough problem" and just dismiss any ideas outright. If it holds no water, the thread will either eventually die, or be resurrected slightly when someone else chimes in. Why smother it? Or the UI could simply asked the cache owner if the corrected data should be saved or just replaced. Use case 1. A CO creates a cache and inadvertently switches the intended values but doesn't noticed until a month after it's been published. The CO corrects the D/T ratings and indicates that they should replace the original values. Use case 2. A CO creates a cache that that requires climbing down and up a steep ravine and gives it a terrain rating of 3.5. A year later a bridge is built over the ravine so the CO changes the T rating to a 2 but want's to keep the 3.5 rating as it indicates the actual terrain rating prior to the bridge being built. You mean like, give the log poster options to choose which data snapshot they'd like to keep with the log? Add more UI features for snapshots and dates, and returning to past logs to change which values to use if a cache changes? .. On the CO side, if it's a mistake, I would think that either having the initial cache info stored when I begin editing, or giving me the option to store the 'new' correct data would be nice and simple. I wasn't thinking of the log poster making a determination which data to use, rather that the CO could choose not to save data that was erroneous, but keep the old data if something actually changed. A terrain rating of 3.5 might be correct before a bridge across a ravine was built, but might not be accurate under the current state of the cache. Quote Link to comment
+thebruce0 Posted January 9, 2017 Share Posted January 9, 2017 I wasn't thinking of the log poster making a determination which data to use, rather that the CO could choose not to save data that was erroneous, but keep the old data if something actually changed. A terrain rating of 3.5 might be correct before a bridge across a ravine was built, but might not be accurate under the current state of the cache. Furthermore, let's keep in mind that almost no one will think of this feature until after the rating's been changed, so it will be virtually pointless to give the user the option unless they are allowed to go back and assert their desire for the snapshot long after they've logged the find. Whereas I've always come at it from the angle of the log poster; the challenge/stats cacher. From what I've seen this issue arises most when a CO changes a property and someone no longer qualifies or don't like that there's a hole in their stats. From the logger standpoint, it doesn't matter so much whether the new stat is changed with the new physical state, or corrected due to an error. If the only people it's relevant to are the people who care about it, then providing the option to the logger seems the best case. Least impact - let the logger decide whether the properties for their own stats are as of the date they logged it or not. Minimally, the CO wouldn't have to do anything because the change is auto-snapshotted (by whatever trigger/period). Every cacher doesn't have to 'learn' something new. It would be a feature only relevant to those for whom it's relevant, in the rare cases it ever happens. But even ignoring all the logging and stat stuff - as a database dev, it does still irk me that there's no changelog for caches (to whatever detail), and that user find statistics aren't actually describing the statistics of the user's finds, only the current properties of caches that the user has marked as found. Ideally, I'd have it set up that the finds do refer to the stats as of the date of the find; in some manner. That to me makes more sense. Added options like choosing which date to pull stats by is a minor thing that only people who'd care to use it would need to see it. But I wouldn't store cache data with each and every find log. Data is cache-specific; lookup is log-specific. How to combine those two? (again, waxing over this because it's what I do for a living; not really intent on any of this actually being implemented in whatever way, though it would be nice to have, even if YMMV, and for me at least, it's fun to work through) Quote Link to comment
Recommended Posts
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.