Geocaching Australia

If we did want to go ahead with this in a managed way, (and I'm not sure this moveable issue is really THAT big a problem). perhaps an approach would be.

1. Propose a GCA solution which is as simple as possible.
2. Request GCA cachers to identify what downstream apps or other software they are using.
3. Approach these downstream systems re the incorporating the change.
4. Coordinate deployment of the changes

Not a trivial task, but not something we couldn't do if the benefits are there.
A lot of this could be done by volunteer coordinators to ease the load on C@W or Craigrat.

I'm thinking that GSAK and GACacher wouldn't be hard to work with.

It would be interesting to see how many people use those other apps for GCA caches.

It's not just people who read this forum who we're talking about here though. There are a lot of people who might use GCA for caching but not ever visit the Forum. For example, overseas cachers coming to Australia just the once. We can't stop anything working that anyone might use.

Don't get fixated on a new log type. Consider the workflow and what will "work" to solve the problem. I am not of the opinion that a new "grabbed" log will solve the problem.

blossom* wrote:It's not just people who read this forum who we're talking about here though. There are a lot of people who might use GCA for caching but not ever visit the Forum. For example, overseas cachers coming to Australia just the once. We can't stop anything working that anyone might use.

You would need to hope that forum users provide a big enough sample to be representative of all local cachers.

Personally I don't think the problem is big enough to bother with trying to fix it, I'm just saying that there is probably a way to go ahead if there is enough push to do it.
AS you point out, there is never a 100% solution, it's just a matter of balancing benefits against effort and resulting issues to clean up afterwards.

caughtatwork wrote:Don't get fixated on a new log type. Consider the workflow and what will "work" to solve the problem. I am not of the opinion that a new "grabbed" log will solve the problem.

Yes, you're still depending on people to do a grabbed log instead of a found log, and to do it in a timely manner.

Not instead. As well.

I find it (to get my count).
I grab it (to tell everyone it's on the way).
I move it (to let everyone know where it is).
vs.
I find it (to get my count) and at the same time log the new co-ords.

Triple the logging.

caughtatwork wrote:Not instead. As well.

I find it (to get my count).
I grab it (to tell everyone it's on the way).
I move it (to let everyone know where it is).
vs.
I find it (to get my count) and at the same time log the new co-ords.

Triple the logging.

I was thinking that it would normally only be 1 or two buttons.
eg
1. Found_Take (so this would be seen externally)
2. Move.
or just
1. Found.
or
1. Move.

is there would be an extra button of action = Found and Taken.

I can't see how that is very hard to understand.

I see that people are saying this is not 100% reliable and I agree but is a whole lot easier to understand that the existing arrangement which is hard to understand
eg Found could = found and left or taken depending on what people say in the log..
where as Found and taken = exactly that easy to understand yes?
so we have a situation which is not ideal an I can't see how improving it makes it worse.
==================================

let me define the problem so we are all on the same page.
1. there is no programmatic way to identify if people have moved cache.
2. there is no standard way of indicating if cache has moved.
3. provide compatibility to GPX standard.

have I missed anything?

If the last log is a 'moved' or a 'found' with coords then you can assume the cache is there? (I think) The only problem is a 'found' without coords. So instead of a 'on the move' and 'in place' status why not 'in place' and 'unknown'?

This seems too simple - what have I forgotten???

ps. I do think you should just read the last log before driving across town to search... and an extra log type is a waste of time and will be annoying...

Righto, as a discussion point:

Here's some other stuff to discuss (if we theoretically did change things):

What do you want to have happen on the site when a movable is found?
Do we take it off the maps and queries and essentially 'vanish' it? Show it on the maps differently?

mtrax wrote:

caughtatwork wrote:Not instead. As well.

I find it (to get my count).
I grab it (to tell everyone it's on the way).
I move it (to let everyone know where it is).
vs.
I find it (to get my count) and at the same time log the new co-ords.

Triple the logging.

I was thinking that it would normally only be 1 or two buttons.
eg
1. Found_Take (so this would be seen externally)
2. Move.
or just
1. Found.
or
1. Move.

is there would be an extra button of action = Found and Taken.

I can't see how that is very hard to understand.

I see that people are saying this is not 100% reliable and I agree but is a whole lot easier to understand that the existing arrangement which is hard to understand
eg Found could = found and left or taken depending on what people say in the log..
where as Found and taken = exactly that easy to understand yes?
so we have a situation which is not ideal an I can't see how improving it makes it worse.
==================================

let me define the problem so we are all on the same page.
1. there is no programmatic way to identify if people have moved cache.
2. there is no standard way of indicating if cache has moved.
3. provide compatibility to GPX standard.

have I missed anything?

I don't think you have missed anything but I am one of those that would vote against having any new type of log for moving caches if it was ever voted on.

You can NEVER be sure that the 'system' reflects the true state of a moving cache so adding extra types of logs just changes the complexity of the logging process and MIGHT improve the system but cannot guarantee it as it relies on logs being recorded as soon as possible after the event occuring.

CraigRat wrote:Righto, as a discussion point:

Here's some other stuff to discuss (if we theoretically did change things):

What do you want to have happen on the site when a movable is found?
Do we take it off the maps and queries and essentially 'vanish' it? Show it on the maps differently?

first of all which maps are we talking about, if its GCA you can mark it with a different icon or just delete either way.
Queries since location is unknown then it should not qualify for location based searches
so essentially the same answer, mark status as in transist ie coords = unknown or how ever ou want to do that internally but externally it shows as unknow
ie much like say .. a travel bug..

Although I am against extra types of logs I have thought about the moving cache processes whilst following this topic.

It seems that it is the last found log that is of most concern with the 'found with coordinates' log type showing only as a found in the system.

Has anyone thought about whether GCA could add in a move log when this type of log is recorded. ie the cacher logs a 'found/coordinates' log but GCA adds in a 'move' log with those coordinates as an additional log. This would then eliminate one of the problems without affecting existing downstream applications.

I realise for a start that a new log type will break most external caching apps like GSAK or Geosphere. That's fine, and they could be approached. But it would still show correctly here - and that's where I tend to look before frogging to check if a frog has been moved or found as the most recent log using a query and it's associated map.

I would see the Found log not necessarily indicate a move, so it stays there.

A Moved log could be made to automatically include a Find so you get the smiley (useful if it's a quick move).

A Grabbed (or Found-Taken) log could be used to indicate it's not longer there, and is in the car waiting to be placed again - more useful as most frogs I grabbed waited until the next day or two to be placed again somewhere. This log type would automatically add the smiley.

As an analogy I guess it could be similar to what is done with travel bugs i.e. Discovered or Taken.

A failsafe would need to be built in so a Found or Grabbed by a cacher followed by a Moved from the same cacher wouldn't generate 2 smileys - though that system also breaks if multiple finds are recorded at an event, and the finder who took it doesn't Move it before other founds are logged.

Actually for a moveable it might be useful if you didn't get the smiley until you had moved it, so a Grabbed doesn't give you one. An incentive to actually put it back out.

Richary wrote: A Moved log could be made to automatically include a Find so you get the smiley (useful if it's a quick move).

This would cause problems for people who find and move a cache for the second time and don't want to have 2 finds on the same cache.

The Found + Moved logs seem to work just fine, but only when both are used. Perhaps a requirement for both log types must be entered (even when replaced in the same location) - say a nag email to log the moved entry? Or a entry for "found and replaced" that adds two logs cloning the coords and hint of the previous moved log?