Jump to content

[FEATURE] Include D/T rating in Found It log


frinklabs

Recommended Posts

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 by Pup Patrol
Link to comment

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?

Link to comment

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 by Pup Patrol
Link to comment

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.

Link to comment

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 by cezanne
Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

 

 

Link to comment

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. :)

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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).

Link to comment

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...

Link to comment

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.

 

 

Link to comment
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.

Link to comment

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 by FamilieFrohne
Link to comment
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.

Link to comment

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.

Link to comment

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)

Link to comment

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. ph34r.gif

 

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. :P

Edited by thebruce0
Link to comment
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.

Link to comment
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. cool.gif

Edited by thebruce0
Link to comment

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 laughing.gif

 

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. ph34r.gif

Link to comment

 

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. :P

 

wayback-machine.geocaching.com

 

 

 

Link to comment

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.

 

 

 

Link to comment

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.

Link to comment
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! ph34r.gif

 

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. tired.gif 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 :P

 

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. laughing.gif

Link to comment
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. laughing.gif

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.

Link to comment
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! ph34r.gif

 

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. tired.gif 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.

 

 

Link to comment
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)

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...