Improving Moveable Caches

Discussion about the Geocaching Australia web site
Post Reply
User avatar
winterdragon
3500 or more caches found
3500 or more caches found
Posts: 308
Joined: 05 March 07 9:50 pm
Location: Adelaide
Contact:

Improving Moveable Caches

Post by winterdragon » 22 January 12 6:48 pm

I did a few caches around the city this morning, with literally dozens of movable caches showing up nearby. I checked the logs for each one on my GPS and as far as I could tell, they'd all been picked up and moved on. It was a tedious process, and as I sat in the heat later on at home, feeling a bit annoyed about it, I had an idea. I'll throw it out there for what it's worth...

Would it be possible to modify the log types on movables to be something like "Picked up" , "Placed", and "Found"? That way you could differentiate between "I've found the cache and am currently moving it to a new location" (Picked Up), and "I've found the cache but left it where it was" (Found). As long as people made the right log entries the system would then know reasonably reliably whether the cache was currently at the listed coords, or in someone's possession.

The next trick would be to convey that info to the user. For on-screen display, perhaps you could just show the status as "In Transit". For GPX dumps from queries (http://geocaching.com.au/my/query), you could set the status to disabled (as I assume the GPX standard doesn't support "in transit"). Or maybe there's another field that could be used - my goal being of course to get something in GSAK that I could use to filter out caches that are "in transit".

Anyway, that was pretty much it. So any thoughts on the benefit of such a system, the difficulty of implementing it, refinements, better ways of achieving the same result? Am I just suffering from heat induced delusion?

User avatar
CraigRat
850 or more found!!!
850 or more found!!!
Posts: 7015
Joined: 23 August 04 3:17 pm
Twitter: CraigRat
Facebook: http://facebook.com/CraigRat
Location: Launceston, TAS
Contact:

Re: Improving Moveable Caches

Post by CraigRat » 22 January 12 7:28 pm

Good suggestions, this has been suggested a few times over the years if you browse older posts!!!

I understand the frustration, I feel it myself when seeking movables!

There's a few technical issues of an immense nature we have to overcome to get it to work on the site

Some reading here:
http://forum.geocaching.com.au/viewtopi ... suggestion

Thanks for your suggestion though!

Laighside Legends
10000 or more caches found
10000 or more caches found
Posts: 1304
Joined: 05 October 10 10:20 pm
Location: Australia

Re: Improving Moveable Caches

Post by Laighside Legends » 22 January 12 8:03 pm

caughtatwork wrote:This comes up every couple of months and (trust me) there is no answer.
CraigRat says no a bit nicer than c@w... :mrgreen:

User avatar
CraigRat
850 or more found!!!
850 or more found!!!
Posts: 7015
Joined: 23 August 04 3:17 pm
Twitter: CraigRat
Facebook: http://facebook.com/CraigRat
Location: Launceston, TAS
Contact:

Re: Improving Moveable Caches

Post by CraigRat » 22 January 12 8:12 pm

I'm professionally trained in saying 'no' :lol:

User avatar
winterdragon
3500 or more caches found
3500 or more caches found
Posts: 308
Joined: 05 March 07 9:50 pm
Location: Adelaide
Contact:

Re: Improving Moveable Caches

Post by winterdragon » 26 January 12 11:51 am

So to summarise... There's a general recognition that moveable caches are broken, and lack of will to fix them :-k .

Working within the constraints of what's available, I've kludged a GSAK macro that filters out all of the "probably in transit" moveables, which I've defined as:
- It looks like a moveable (it has a GA code, is of type "Other", and it doesn't start with "B&W")
- The last log didn't include coordinates (only looking at logs of type "Found it" and "Noted")
There's the case where there were more than one log on the last day, but rather than try and resolve these cases, I've just thrown them into the "probably in transit" basket.

It's not pretty, it's not elegant, but it will let me discard a whole lot of moveables so I can focus on the ones which are probably there. Which is good enough for me! And in case it's of interest to anyone else, here it is...

Code: Select all

MFILTER Where=CacheType = 'O' AND Code like 'GA%' AND Name not like 'B&W %' AND Status = 'A' AND Code in (select p from (select lParent p, lLat lat, count(lParent) cnt from logs, (select lParent par, max(lDate) date from logs where lParent like 'GA%' AND lType = 'Found it' OR lType = 'Note' group by lParent) logs where lparent=par AND lDate=date group by lParent) where cnt>1 OR lat = '')
Once you filter these out, it's up to you what you do with them. Personally I just mark them as disabled so that they're left out when I export to GPS.

User avatar
mtrax
Posts: 1974
Joined: 19 December 06 9:57 am
Location: Weston Creek, Canberra

Re: Improving Moveable Caches

Post by mtrax » 26 January 12 12:27 pm

I just thought of another idea perhaps we can store the "Taken status" in the "Hint" field, this would allow compatibility with GPX and allow this to be an optional field.
ie have a tick box or drop down to "mark Hint Taken"

Paul

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 26 January 12 1:26 pm

winterdragon wrote:So to summarise... There's a general recognition that moveable caches are broken, and lack of will to fix them :-k .
I'll take offence to that on behalf of the development team. There is no lack of will to fix them. Their location cannot be determined by programming.

A cache that has moved to a new location may STILL be gone when you get there as someone was there 2 minutes before you got there.

A cache that has been found and has no new co-ordinates may be on the move, it may not. We could make a new log type of "found and picked up". How's GSAK or your GPS going to handle that? It won't. The only place that would handle a "found picked up" log would be the GCA website. So any queries you get emailed to you will have the new log type in it, but no program currently out there will handle it. Nor will any mobile app.

Creating new log types at GCA is easy. Getting the hundreds of third party apps to recognise the new logs types, impossible.

We have been over this point a number of times in the past and there is no way to determine where a cache is, if only because it was found 2 minutes ago and it's off to somewhere new.

"Probably in transit" is not good enough for some people who will want a guarantee that the cache is in location. Do you have a lack of will to write a macro that will guarantee its location?

We can leave the situation the way it is now, with most apps working well enough to get the best info it can.
We can change the situation to break most apps when they don't recognise the new log types and there's still no guarantee the cache is in place.
We can make moving caches so complex to log that people don't bother to do that and you're back at square one with people taking the easy way out at logging time leaving the cache possibly at point A, point B, somewhere in between.

My point is that we have looked at moving caches many times over the years and because they can be moved while you're not looking, you simply need to do some work at your end to make a best estimate guess as to whether you want to try and find it. It's not lack of will. It's a lack of capability in the 3rd party apps that keeps the moving caches where they are now.

User avatar
mtrax
Posts: 1974
Joined: 19 December 06 9:57 am
Location: Weston Creek, Canberra

Re: Improving Moveable Caches

Post by mtrax » 26 January 12 1:38 pm

perhaps a FAQ for this topic so people understand the issue, I certainly didn't till now.
ie a copy paste of the above should do it.

User avatar
winterdragon
3500 or more caches found
3500 or more caches found
Posts: 308
Joined: 05 March 07 9:50 pm
Location: Adelaide
Contact:

Re: Improving Moveable Caches

Post by winterdragon » 26 January 12 2:41 pm

caughtatwork wrote:I'll take offence to that on behalf of the development team. There is no lack of will to fix them. Their location cannot be determined by programming.
Sigh. Apologies C@W, it was meant half tongue in cheek, and I should have plastered the statement with suitable emoticons to signpost that. How about if I change it to "The problem has been deemed too difficult to completely fix" instead?
caughtatwork wrote:A cache that has moved to a new location may STILL be gone when you get there as someone was there 2 minutes before you got there.
Agreed. And a traditional cache may not be there when you look for it either. At the end of the day you need to apply some common sense, read previous logs, and make a call.
caughtatwork wrote:"Probably in transit" is not good enough for some people who will want a guarantee that the cache is in location. Do you have a lack of will to write a macro that will guarantee its location?
Absolutely! Life is too short to solve every problem completely. Everything you do is a compromise. In this case, I have constraints on time, my knowledge & ability, the data that's available to work with, etc. My own value system tells me that the value added exceeded the cost of the effort expended, and I'm satisfied with the half-assed results. After all, I only did it for myself. Posting it to the forum was just a bonus. If nobody made anything public unless it was perfect, there'd be no open source software. And if other people aren't happy and want more, then they're welcome to do the work. Want to write a natural language parser that will interpret each log and determine whether it's a placed, found, or picked up? Sure, be my guest!

In my case, I had at least 20 moveable caches within 1km. I started scrolling though previous logs for each one on my tiny GPS screen, and in each case it looked like they'd been picked up. After about 5 of these I just gave up, and so collected 0 movable caches. If I'd used my filter to narrow down to few that were likely to still be there, I might have collected 1 or 2 instead. Nett gain = 1 to 2 caches.
caughtatwork wrote:A cache that has been found and has no new co-ordinates may be on the move, it may not. We could make a new log type of "found and picked up". How's GSAK or your GPS going to handle that? It won't. The only place that would handle a "found picked up" log would be the GCA website. So any queries you get emailed to you will have the new log type in it, but no program currently out there will handle it. Nor will any mobile app.

Creating new log types at GCA is easy. Getting the hundreds of third party apps to recognise the new logs types, impossible.
I don't want to get into a long argument. See above - "Life is too short". But I'll just point out that GCA has a number of cache types that don't map to types available in GPX. Like moveables for instance. But we make them work as best we can, by mapping to type "Other" for example. We compromise.

Also, GCA is already generating non-standard log entries. For example, in a GPX from GC, a note log has type "Write Note". In a GPX from GCA, it has type "Note". GSAK happily ingests both, and even places the note icon against both. Good old Clyde is already dealing with GCA specific log types!

Please note that I'm not trying to say it's easy. I accept that there are significant technical challenges. I'm also keenly aware that the website is entirely built and managed by volunteer effort, and I'm appreciative of that effort, and in no way trying to diminish it. However, it does mean that there's very limited time to spend on making updates, and you always have to make a judgement call about which updates are worth pursuing, and which are not. In this case I've made my case, and your expert call is that it isn't worth it, so I accept that judgement.

Anyway, as I think I may have already mentioned, life is too short for writing these long responses. I'm going to go find some caches instead. And now I won't be distracted by all those moveables that probably aren't even there :D

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 26 January 12 2:47 pm

The wiki has been updated.
http://wiki.geocaching.com.au/wiki/Moveable_cache
I doubt people will read it (RTFM, really?), but it is now captured for reference.

If anyone can actually come up with a system that works (remember that people do their logging in different ways to you), then feel free to post the answer. Please don't be offended when we poke a hole in it. I've been trying to solve this challenge since 2005 and haven't got an answer yet. As such sometimes I will respond with a "can't be fixed, trust me", because I truly believe it cannot be addressed and better than we have now. All we do is add complexity and confuse 3rd party apps.

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 26 January 12 2:58 pm

I've been commenting on the "fix it" type comments for about 7 years now, so yeah, when I get told I have no "will to fix it", I get snarky. The best natural language parser is you, so we leave the decision to you to determine whether you would like to look for the cache. I can say, with 100% accuracy, that if we implemented a solution that have 80+% accurate results, people would still bitch about the remaining 20%. If we then improved it to 90%, then we get bitched at about the remaining 10%. Make is 99% and then we get the 1%. Not from you, not now, but someone in the future will. You can trust me on that one.

GSAK handles the GCA GPX Schema correctly because Clyde knows what he's doing. Almost every other app will fail against the GCA schema because the developers think that GC is the only place to generate GPX files and only reference the GC schema.

Go find any app and import a GCA GPX file. Almost guaranteed to fail. Almost. There are some that work.

Yes, we do have an "other" cache type and log type. We then fall into a position where is an "other" log type an "in transit" or some other "other" log type. You need to look and read. It's essentially no different to now. You look at the last log, moved, good to go. Found and new co-ords good to go. Found and no co-ords, read the log and see.

By your own admission, the macro is not perfect, so we are in agreement there is nothing we can do. Adding logs adds complexity and if you get them in the wrong order, all hell breaks loose. People do not cache the way you or I do not do they log that way either. We try to keep complexity to a minimum so we have two logs types. Found and moved.

The cacher simply needs to add the time to check the log and decide if they want to go find it. You have done that by macro and I'm sure some people will use it. As far as the system being able to determine the location, it's simply not possible.

User avatar
mtrax
Posts: 1974
Joined: 19 December 06 9:57 am
Location: Weston Creek, Canberra

Re: Improving Moveable Caches

Post by mtrax » 26 January 12 3:04 pm

Can we use the "Hint" field to indicate Moved or In-transit?

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 26 January 12 3:09 pm

?Why not just add it to the log?

Found and taken.
Found but not taken.

I try to use that terminology in my logs.

If you use the hint and say "not taken", then the previous hint which explained where the cache was will be overwritten with "not taken". That doesn't help anyone.

I would very strongly suggest you do not kludge values into fields not intended for that purpose. You will annoy some and help others and those who are annoyed will hunt you down and tell you to "fix it". Kludging values into fields not intended for that purpose is a highway to doom, very, very fast. I really recommend you do not do this.

Remember, people WILL NOT do as you ask. They will do as they please. Allow them to cock up the previous hint by making the new hint "not taken" and they will. Not through malice, but through not understanding the field purpose.

User avatar
mtrax
Posts: 1974
Joined: 19 December 06 9:57 am
Location: Weston Creek, Canberra

Re: Improving Moveable Caches

Post by mtrax » 26 January 12 4:24 pm

caughtatwork wrote:?Why not just add it to the log?
Found and taken.
Found but not taken.
I try to use that terminology in my logs.
If you use the hint and say "not taken", then the previous hint which explained where the cache was will be overwritten with "not taken". That doesn't help anyone.
I would very strongly suggest you do not kludge values into fields not intended for that purpose.
is this exactly what the hint is for.. to give person a hint that its taken?
ie hint = clue to where the movable is..

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Improving Moveable Caches

Post by caughtatwork » 26 January 12 5:19 pm

Yes, but if you FIND it and DON'T move it and ADD "Not taken" as the hint, it's pointless. Sure, you now know it's still there (but only if you read the hint and if you're reading the hint you may as well read the log), but the previous hint has been replaced with something useless.

As a programmer of hundreds of years, anyone who tries to kludge data into another field is going to end up in trouble. Don't do it.

Post Reply