Geocaching Australia

I have found that the moving caches move so often that whatever is on my gps is not up to date by the time I get from home to work, or work to home. Or from when I go to bed to when I get up.

My really simple solution to that, is to spend a few minutes looking at the "My Query" for the moveables before I go (frogs this year, gnomes last year etc). If you list them on the screen, it is really, really easy to see if the last log was a move and then it's going to be in the spot that the co-ords say Then just download the ones you want to look for.

I really think the GCA screen view gives you all the info you want. Trying to duplicate what's shown there on various other systems is a bit like becasue the owners of the other systems will not care too much about our suggestions usually.

Using the Hint field for somehthing else isn't going to do an awful lot. It's probably just as easy to read the last log as it is to read a hint that isn't a hint any more.

Moving moveables is a fact of life, you always take your chances and sometimes you are lucky, sometimes you are not.

It has happened a few times this year and last year that I have done the trip to Sydney (3 hour train trip) only to find that my target has been taken. It is all part of the fun and accept it as such (with a bit of cursing and swearing!). I remember a trip when all 7 of my targets had gone and I had to go back home empty handed.

For me the easiest way is to make it clear in your log as to whether the moveable has been taken away or left in place.

I can't think of an answer that will satisfy everybody, all I can say is "If it ain't broke, don't fix it".

Can it be changed that you must use a 'Move' action to actually move a moveable. I find that some use a 'Found' to move a moveable so it's impossible to know whether a moveable has been moved. You run a Query or look at the list & ignore all moveables that don't have a Moved blue arrow when in fact some have been Moved but the mover used a Found to move the moveable.

As an example someone finds the moveable, records same & gets a green tick. They then move it but use another Found to add the new co-ords. The stats look good but for the rest of us it hasn't been moved.

Tuena wrote:Can it be changed that you must use a 'Move' action to actually move a moveable. I find that some use a 'Found' to move a moveable so it's impossible to know whether a moveable has been moved. You run a Query or look at the list & ignore all moveables that don't have a Moved blue arrow when in fact some have been Moved but the mover used a Found to move the moveable.

As an example someone finds the moveable, records same & gets a green tick. They then move it but use another Found to add the new co-ords. The stats look good but for the rest of us it hasn't been moved.

I think this IS a subject worthy of discussion and consideration. Should you be able to log the new co-ordinates for a moveable just in your "found" log? I would vote no for this. You should log the find when you find and pick it up. Then when you move it, you should log the move. Most people do this but I have often forgotten to change the log type to move when i do log the move becasue there is a spot there for the co-ords in the found trype of log and I just put them in. Then I realise and have to edit my log to make it a mvoe. And it's not uncommmon for others to do this too.

So is this possible? Or is it a function of the cache type that the co-ords have to be there?

The question is who benefits and who is disadvantaged?

For a person trying to find the cache an enforced FIND then MOVE makes it easier.
For a person trying to rehide the cache an enforced FIND then MOVE makes it harder. i.e. I can accomplish both with a FIND.

Adding to this. I want to move caches along, but do not want to log another find. I want only unique caches in my finds tally. So I pick it up and rehide it and ONLY use a MOVE log. Enforcing a FIND then MOVE means I HAVE to have that same cache added to my list again.

Do not view the challenge from one perspective. Consider all people who play the game. Some want simplicity of logging. Some want simplicity of a MOVE and do not want to count the cache as found again. Some want the cache easily identified as where it is now.

Enforcing a logging structure advantages some and disadvantages others.

caughtatwork wrote: Adding to this. I want to move caches along, but do not want to log another find. I want only unique caches in my finds tally. So I pick it up and rehide it and ONLY use a MOVE log. Enforcing a FIND then MOVE means I HAVE to have that same cache added to my list again.

Yes, I can see all your points. However, I was only suggesting stopping being able to log the move in a FIND log. For the above case, there should be no impact. This person (and I've done this quite often myself) can still use only a MOVE log. I was not suggesting they have to log a FIND first before they're "allowed" to log a MOVE.

caughtatwork wrote: For a person trying to rehide the cache an enforced FIND then MOVE makes it harder. i.e. I can accomplish both with a FIND.

Yes, the person who wants the simplicity of logging just once but still wants to get the smilie would be inconvenienced. IMHO most of the moves that appear in the FIND logs are actually the second FIND log by that cacher for that cache at that time though - ie a mistake (and often by newer GCA cachers). But I do agree there are a few times that some people actually want to find and move in one go.

Quick question, a bit off the current topic but still moveable related; Is there a clever way to deal with the issue when several moveables are hidden at the identical spot? On the map, one is on top and you (well, I can't) can't get past it.
It's become an issue to us with the frog race. Frogs appear to be sociable critters and are bunching up.

nutwood wrote:Quick question, a bit off the current topic but still moveable related; Is there a clever way to deal with the issue when several moveables are hidden at the identical spot? On the map, one is on top and you (well, I can't) can't get past it.
It's become an issue to us with the frog race. Frogs appear to be sociable critters and are bunching up.

I for one don't know of any way of separating stacked frogs on the map; I presume that when the frogs have the same coordinates they HAVE to appear on top of each other.

What I've been using is a My Query, in order to find all leap frogs close to me. I then use this in three ways: I use "Screen" to get a list of the caches on the screen and I skim down the list to see which ones are the same distance away, since this usually (but not always) means that they are in the same position. I use "GMAP" to view them on the Google maps to see roughly where they are so that I can plan my trip (knowing that there'll be some together). I open up "Screen" and "GMAP" in separate tabs/windows and swap back and forth between them as I get my head around what's where (including whether or not they've actually been found and so probably aren't at their listed coordinates). Finally, I use GPX to get the data in a format that I can transfer to my GPS. In addition (yes, fourthly and after "finally") I'll sometimes use internet access in the field on my phone to do a double check in case one or all of the little critters have been picked up.

I missed a frog recently because it had been placed about 10 metres from another one. Unfortunately I only used the map function on Geosphere instead of the list so I didn't realise there was a second one there. I was sort of expecting two frogs placed near each other to be in the same spot.

I doubt there is a solution though, except to look at the list - which seems to be necessary anyway to work out which are there and which have already been found but not moved as yet.

GMaps do not have a simple way to do this

Google EARTH does, but we would have to manually code a solution that would be a reasonable performance hit (we have to get every cache and test to see if there are other caches nearby just to change a pin on the map.....)

not saying we WONT do it, but it's not a trivial thing to hack in without having a detrimental impact on the server and the maps!

Thanks all. I thought there might be some clever way that we're missing but apparently not. We've settled in to utilising queries, as per Sam Carters method but still find it frustrating when you want to look at the map, especially when the frog that's the top of the "heap" is sitting on the desk next to you, awaiting re-location!

CraigRat wrote:GMaps do not have a simple way to do this

Google EARTH does, but we would have to manually code a solution that would be a reasonable performance hit (we have to get every cache and test to see if there are other caches nearby just to change a pin on the map.....)

I guess in most situations caches are supposed to be 161 metres apart (at least for GC guidelines) so the problem doesn't arise. The race moveables are a bit of a special event, and it probably isn't a situation that comes up too much in normal caching. AFAIK you can have the pins in 4 directions, so it still wouldn't work if there were more than 4 frogs in the one spot. I wouldn't worry about it.

People when searching don't just use the map, open the page for the frog that is shown, then click on Nearby GCA and you can see if others are there as well.

Yes I stopped using the map and just used my query and my problems were solved. You can even sort them by clicking the 'logs' heading and all the caches with the last log as 'moved' will appear together in order of distance from your home. Mind you the first time you click 'Logs' you will get the DNFs listed first (actually unfound first but there's only one) but if you click 'Logs' again you get all the 'Note' logs followed by the 'Moved' logs which allows you to pick the ones that are most likely to be there still, barring very recent finds without logs.

Works for me!

Here's a thought ... which I am prepared to concede, in advance, may be totally stupid. It's also way too late for the Frog race, but might be useful in future for any moveables.

On the maps page, when you click on one of the location marker icons that indicate the location of a cache you get a little pop-up cartoon speech bubble that lists the cache name, hider, and cache type, and it also allows you to link off to the cache page. Perhaps in the speech bubble you could also give a string of five icons showing the last five log types (like the tick-moved-cross-tick-note set of icons that are listed on the Screen page of a My Query). I guess this means a data call of the last log types each time this is done, but it means you get the recent log statuses shown on the map page. I find the recent log list on the Screen Page useful (I generally don't go looking for anything that has a "found" as the last log, but will if it has "moved" as the last log (and I know this means that I might be failing to look for a few special cases where the cache has been found but not picked up, but that's my responsibility)

In fact, this might even be a useful thing for non-moveable caches as well.

Would this be useful? Is it doable?

Useful, yes, doable, yes.
(The last 4 log types are kept with each cache for quick recall)