Page 6 of 8

Re: Improving Moveable Caches -- Don't Fix it!

Posted: 02 February 12 8:00 pm
by pjmpjm
rogerw3 wrote: Please keep the moveables as moveables, and yes I do know that sometimes you will get to GZ only to find that the cache has... well... moved, that is the whole point of it. Yes it would be nice if people made it clear in the find log whether they have taken the cache or left it in place, but really how often is this ambiguous, in my experience once or twice in the last 2 months. I can only repeat what I have said before "If it ain't broke, don't fix it!".
Agreed.

Ultimately, you have to rely on the individual geocacher to enter some kind of useful information in the moveable's log -- and to actually enter that useful information online, within a reasonable time frame. No software changes can guarantee that.

:frogette :gnome :gnomette :frog

Re: Improving Moveable Caches

Posted: 02 February 12 9:08 pm
by Richary
One thing that I read earlier in the thread (I think it was C@W) was that people didn't seem to value moveables as the logs were short.

IMHO there are two reasons for the short logs.

1) If I found one and wasn't going to be back at the computer soon, to try and do the right things by others I logged it on the iPhone straight away. Now with my ageing eyesight and fat fingers typing a long log on the iPhone keypad is just not going to happen. I can touch type much quicker on the laptop.

2) Part of the attraction of a good cache that we all talk about is things like the location, history or quality of the hide. With a moveable there is no point in congratulating the owner on any of those things, except the quality of the moveable. So there is less to say in the log, and its not relevant to the next finder (if you've moved it).

So I wouldn't assume that short logs mean people don't enjoy them. Just my 2 cents worth.

Re: Improving Moveable Caches

Posted: 02 February 12 9:55 pm
by caughtatwork
mtrax wrote:
caughtatwork wrote:So we're forcing 3 logs.
Find
Grab
Move

Whereas right now I do one log for Find and Move.
How is three times the work an improvement?
the improvement ,as above
Three times the logging to solve the occassional need to read a log is not an improvement. It's a step backwards.

Re: Improving Moveable Caches

Posted: 02 February 12 10:38 pm
by mtrax
caughtatwork wrote:
mtrax wrote:
caughtatwork wrote:So we're forcing 3 logs.
Find
Grab
Move

Whereas right now I do one log for Find and Move.
How is three times the work an improvement?
the improvement ,as above
Three times the logging to solve the occassional need to read a log is not an improvement. It's a step backwards.
Wait I thought you said you always need to read the log, having a good logical means to determine location is a move forward right?
In any case this is not a valid argument against the idea

Re: Improving Moveable Caches

Posted: 02 February 12 11:13 pm
by caughtatwork
If I did I was wrong, but I can't see where I said that.

At the moment, it's simple.
Found and no co-ords. Read the log.
Noted and no co-ords. Read the log.
Found and co-ords, probably moved and in place.
Notes and co-ords, probably moved and in place.
Moved and co-ords, moved and in place.

There are essentially two possibilities for any log type. If the log has co-ords, it's moved. If it doesn't ... read the logs to see what the status is.

Re: Improving Moveable Caches

Posted: 03 February 12 8:13 am
by mtrax
caughtatwork wrote:If I did I was wrong, but I can't see where I said that.

At the moment, it's simple.
Found and no co-ords. Read the log.
Noted and no co-ords. Read the log.
Found and co-ords, probably moved and in place.
Notes and co-ords, probably moved and in place.
Moved and co-ords, moved and in place.

There are essentially two possibilities for any log type. If the log has co-ords, it's moved. If it doesn't ... read the logs to see what the status is.
vs

Found .. its there!
Noted . .. read the log? who knows ???
grabbed : do nothing you know its not there
Moved and co-ords, its there!

ie you removed ALOT of uncertainly and guess work etc..

Re: Improving Moveable Caches

Posted: 03 February 12 8:38 am
by rogerw3
Keep in mind that not all cachers have the mean to do instant logs. In my case I do not have and cannot afford any of those gizmo's, I have to wait until I get back home, a 3-4 hours train trip to do the logs, I may have taken and/or moved any number of moveables in the morning and not be able to log them until late in the evening.
No matter what kind of logs you use there will still be no way for you to know if the cache is in place or not for a few hours until I can get the logs done.

Re: Improving Moveable Caches

Posted: 03 February 12 1:27 pm
by blossom*
rogerw3 wrote:Keep in mind that not all cachers have the mean to do instant logs. In my case I do not have and cannot afford any of those gizmo's, I have to wait until I get back home, a 3-4 hours train trip to do the logs, I may have taken and/or moved any number of moveables in the morning and not be able to log them until late in the evening.
No matter what kind of logs you use there will still be no way for you to know if the cache is in place or not for a few hours until I can get the logs done.
Ah yes, but the way around this is to have a watch put on the trains at Lithgow :twisted: When you spot rogerw3 boarding the Sydney train, you can be pretty certain that anything within a few kms of any train station will be gone by the time you head home from work :-"

And that anything that is currently residing near Lithgow or Cllyywwdd will be in Sydney for either a late night dash or an early morning detour on the way to work \:D/

Re: Improving Moveable Caches

Posted: 03 February 12 1:48 pm
by caughtatwork
mtrax wrote:
caughtatwork wrote:If I did I was wrong, but I can't see where I said that.

At the moment, it's simple.
Found and no co-ords. Read the log.
Noted and no co-ords. Read the log.
Found and co-ords, probably moved and in place.
Notes and co-ords, probably moved and in place.
Moved and co-ords, moved and in place.

There are essentially two possibilities for any log type. If the log has co-ords, it's moved. If it doesn't ... read the logs to see what the status is.
vs

Found .. its there!
Noted . .. read the log? who knows ???
grabbed : do nothing you know its not there
Moved and co-ords, its there!

ie you removed ALOT of uncertainly and guess work etc..
Found = Maybe there, maybe not because they haven't logged a grab yet.

You seem to be confusing an "end state" with a "transitional state". I agree that after all logging is done and dusted maybe a day after the action, it would be "one log type clearer". In the transition period of a game, found does not mean it's still there. It could be on the move, but not yet logged.

I am still entirely uncovinced that this is a better solution.

Re: Improving Moveable Caches

Posted: 03 February 12 3:07 pm
by mtrax
caughtatwork wrote: Found = Maybe there, maybe not because they haven't logged a grab yet.
I am still entirely uncovinced that this is a better solution.
Found = exactly that , ie not moved not grabbed

Now if the person logs a find and takes it I can't be expected to know that, but this is true now so I'm assuming when people take it that log a "Grab" the same way your assuming people do that now.
therefore this log type adds more certainty and clarity.

We can't anticipate people doing the wrong thing we can only assume that follow the process much like road rules.

I haven't seen any blockers for this Log-type so I can't really explain why you think its bad.
ie I've answered all these questions but still hard to figure out what the real issue is? or perhaps I have missed some suitable issue ?
perhaps if you can start with the technical issues then we can move onto the intangible ones.

Re: Improving Moveable rogerw3

Posted: 03 February 12 3:25 pm
by pjmpjm
blossom* wrote: Ah yes, but the way around this is to have a watch put on the trains at Lithgow :twisted: When you spot rogerw3 boarding the Sydney train, you can be pretty certain that anything within a few kms of any train station will be gone by the time you head home from work :-"
Even watching rogerw3's movements via webcams could prove to be a tiring business . . . :frogette :gnome :gnomette :frog

Re: Improving Moveable Caches

Posted: 03 February 12 4:11 pm
by caughtatwork
We keep saying the same things.

You seem to think found indicates something that you can work with. i.e. It's found and not moved.

I'm saying found may be gone. Either way, in that interim period until you know there are no more logs coming through, you don't know whether it's found and in place or found and the moved is yet to be logged.

Coming back to my first point about my use of the site.
1 log: Found with co-ords. That's all I want to have to do.

For your ease you want me to log a found, grabbed and moved.
I am not now, or in the future, going to log three times.

You have a concern with the found log by not knowing whether it has been found and taken or found and left in place. Even in the new 3 log solution, found may be there or the cache may be awaiting a grabbed log. i.e. You don't know whether it's been found and taken (awaiting a grabbed log) or a found and left (no logs to come through). i.e. You are in no better position that we are right now.

As far as the technical aspects go.

Found = understood by most (if not all) apps and programs.
Grabbed = understood by nothing apart from the site.
Moved = understood (possibly by GSAK) and the site.

So adding new log types will:
a. Not make it easier for apps or programs to know the status of the cache as they won't know what the hell a grabbed log type is.
b. May cause the app or program (and the device) to crash.

If you are looking for the GCA website to tell you where the cache is, we can do that by way of simple tick box against a found log. "I have taken this cache". If that's ticked, it's not there. You still need to check the cache page to see what the status of the cache is. How we can represent that into a GPX file is a technical challenge because the GPX format has nothing that you can use and I will not hack data into another field. A note (auto generated) from the tick box) may work.

If you are looking for any other 3rd party app to tell you the same, you're out of luck.

CraigRat have worked with many GPX file parsers and apps over the years and with 2 (I think) exceptions they do not care about anything that's not GC, so they will not take the time and effort to cater for log types that GC do not generate. To expect that they will work with us is a fallacy.

Please tell me how a 3 log solution works for me. You say it will work for you, that's fine. Please explain to ME how logging 3 times vs. 1 time is any bnefit to me at all. I'm now looking at this from a personal (not a developer) perspective. Your proposal is 3 times the work for me. Do not like. Do not want. Will not do. So an explanation of how I can log 1 time and still allow you to know (maybe) where the cache is may sway my mind, because at the moment, all I get is 3 times the logging.

Re: Improving Moveable Caches

Posted: 03 February 12 4:29 pm
by Trigg-A-Nomics
caughtatwork wrote:There are essentially two possibilities for any log type. If the log has co-ords, it's moved. If it doesn't ... read the logs to see what the status is.
Could we extend this a little on the GCA site? At the moment there's no way to distinguish between a "Found" and a "Found with coords" log from the icon on the search page, log page and maps (awesome addition). =D>

What if we could distinguish between those two log types (different icon? different tick colour?). Then you could look down the list or on the map, see the ones with moved or found with coords as the last log and *BAM* you're out the door and hunting! :gnomette :frog

In the non-racing months I keep my GSAK up to date by reading the moveable logs and disabling those that aren't there. I don't have a lot of time to plan my caching nowadays - it's usually a two second look "Hmmm, are there any moveables I can grab on the way home?" so this would be a helpful addition.

Re: Improving Moveable Caches

Posted: 03 February 12 6:50 pm
by Laighside Legends
Laighside Legends wrote:How about we say 'its there to find' if the last log was a 'moved' or 'found' with coords
and say 'see logs for location' if anything else

It wouldn't get 100% of the ones that are ready to be found but it would get a reasonable number...
Would someone tell me why this wouldn't work??? :-k

Re: Improving Moveable Caches

Posted: 03 February 12 7:32 pm
by caughtatwork
It does. It's what happens now. That's what I personally check for when I look at moveables.

If it was moved, it's there (assuming no one else has found it in the meantime).
If it was found with co-ords, it's been moved (ditto).

The thing people are not happy with is a found.
Was it found and left behind?
Was it found and taken?

Really that's the only thing this whole train-wreck is about. If it was found and there are no co-ords, check the logs. If you can't determine that it's been taken, try for it. If you can determine that it's been taken, don't look for it. If you can't determine from the log, well, choose a poison. Try and fail. Try and succeed.

Without another log being made (like a grabbed), you aren't sure. But a grabbed doesn't solve the problem while the cache is in transition. A grabbed only works when ALL of the logging for the cache has been done.

I'm opposed to a new log type for the reason I've outlined a number of times.

The challenge now becomes can the system determine the status? Let's say found and co-ords. It's been moved. Woohoo! Status: MOVED AND IN PLACE.

Then a log that is a found and no co-ords. Damn. Maybe left behind maybe in the process of moving OR the logs are out of order. Status: UNKNOWN.

Except that the logs are out of order. An event or something else. Two people found and moved it. A logged the find AND the grabbed AND the move. B logs the found only. They log back to front. Status: UNKNOWN

So you see, REGARDLESS of what the logs are, the system CANNOT know where the cache is. YOU, as a clever human, can make a determination of the status.

Of course, if we DID set a status, then we would have a bunch of people bitching that the status is WRONG.

If I can't get the status RIGHT, then then is no point in anything we have discussed. You STILL need to read the logs and make a judgement call.

5 pages in and I am still of the opinion that what we have now works for the most part. You need to take a moment to read the logs and make a decision. Anything I do in the system you STILL need to check because there are situations that can make the status WRONG.