Moveable caches can be extremely innovative. There are a number of moveable caches that are used to play a giant game of Battleships!
Logging a Moveable Cache
As moveable caches can be quite creative, please check the cache page for special logging requirements. With a normal moveable cache, follow these steps to log your find and move.
First Step: Log your find with a 'Found' log (this will give you your smiley!)
Second Step: When you have moved the cache to its new location, log a NEW 'Moved' log, adding the new co-ordinates and even a hint in the hint box if you wish. The hints box will update the main hint for the cache so that it will update in GSAK and the like.
Note that you can also effectively move a cache with a found log. Log your find with a 'Found' log to give you your smiley and add the new co-ordinates and a hint to the applicable entry boxes. This will update the cache location and the hint and will also give you your smiley for finding the cache.
Moveable Cache Games
From time to time, Geocaching Australia organises a game involving moveable caches. This involves participants hiding moveable caches, which then race around Australia and the world. Prizes are sometimes awarded based on the performance of the geocache during the race. Two recent moving cache races have been:
- Moving Cache Race, 1 Dec 2009 - 31 Jan 2010
- The GeGnome Project, 1 Dec 2010 - 31 Jan 2011
- Leap Frog, 1 Dec 2011 - 31 Jan 2012
- Bingo, 1 Dec 2012 - 31 Jan 2013
- Weeping Angels, 1 Dec 2013 - 31 Jan 2014
- GeGnome II Electric Boogaloo, 1 Dec 2015 - 31 Jan 2016
Where is the cache?
A moving cache, by nature, may have been moved since you last determined its location. It may have been picked up but not yet rehidden so it's considered 'in-transit'. There is no foolproof method of determining where a cache is simply by the log types that have been placed against the cache. In general the following applies:
- A moved log with new co-ordinates indicates that the cache is in the new location ready to be found.
- A found log with new co-ordinates indicates that the cache is in the new location ready to be found.
- A found log with no new co-ordinates may indicate one of two situations:
- The cache has been found and left in place.
The best way to determine this is to read the found log and hopefully the cacher who found the cache has indicated whether it is still in place.
- The cache has been found and the cacher has taken it away to re-hide it.
The best was to determine this is to read the found log and hopefully the cacher who found the cache has indicated whether they have taken it away.
- The cache has been found and left in place.
In essence, you will need to read the last log to determine whether the cache is in place or whether the cache has been moved. Remember that even though the logs indicate the cache may be at a certain location, it may have been picked up and moved only moments before you arrived. That's part of the challenge of a moving cache; you're never quite sure whether it's a DNF because you can't spot it or it's been moved along.
Fix the system so I can tell where the cache is
There is no possibility of 'fixing' a system that isn't broken. To keep the confusion to a minimum when logging caches, GCA only offers a "found" and a "moved" log type. As you can read above, a found log may end up with one of two situations. It's still there or it's been moved.
Suggestions has been made over the years to introduce a new "in transit" log type. This would mean you would need to log a "found", then an "in transit", then a "moved" log to complete the scenario. i.e. You find it (found), you take it home (in transit) and relocate it the next day (moved).
For people who are hiding "on the run", they may pick the cache up and re-hide it within the hour. This means they would only need to log a "found" with new co-ordinates where the cache was re-hidden. So if you were looking for a "moved" log to determine the location, you would miss the new location as it's against the found log.
For someone who only finds the cache and leaves it in place, they will only ever log a "found" log. So if you were looking for a series of "found", "in transit" and "moved" you would never know that the cache is still in the same location.
However, if they are going to move it on, the might log a "found", then have dinner. You see the found log and think it's still in place whereas it's actually in the boot of their car awaiting an "in transit" or "moved" log.
As moving caches take time to move, some people will log some log "in the field" using mobile devices and some will log them all at home. You cannot be guaranteed that any given log indicates 100% that the cache is there or not.
Adding to the final complexity of the "fix" is that 3rd party applications (like iOS, Android mobile apps or programs such as GSAK) will not understand an "in transit" log type. They will either fail and abort parsing of the GPX file, create something generic such as "unknown log type" or behave is some other unanticipated fashion. Simply putting a new log type into the GPX file and GPX schema does not ensure that 3rd party applications will handle the new log types. It is almost impossible to get every single application to use new log types in any short period of time, this could render your favourite application with a fatal flaw should it not read the GPX file properly.
So in summary, the system is not "broken", it simply cannot be "fixed" to determine the cache location for you, either at GCA or on your 3rd party mobile application. You will need to look at the log type, read the log and decide if the cache is in location A, location B or somewhere in between.