Improving Moveable Caches

[CraigRat]

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

Would this be useful? Is it doable?

Done!

(Well almost... not working on queries for some reason)

[SamCarter]

I was about to say "You guys are awesome" but I have to hold it in reserve for a minute or two. It's not quite working (for me) yet. I get the extra line that begins "Last logs" but the icons themselves aren't showing -- there's just a blank space. I'm running Firefox 9.0.1 on a Mac. I checked with Safari (5.1.1), and I get four question-mark icons, suggesting it can't find the needed images. Don't have IE to check there.

[CraigRat]

I was about to say "You guys are awesome" but I have to hold it in reserve for a minute or two. It's not quite working (for me) yet. I get the extra line that begins "Last logs" but the icons themselves aren't showing -- there's just a blank space. I'm running Firefox 9.0.1 on a Mac. I checked with Safari (5.1.1), and I get four question-mark icons, suggesting it can't find the needed images. Don't have IE to check there.

Yep, getting that myself on query related maps. workin' on it!

[CraigRat]

Done! sorry for the delay!

[SamCarter]

Done! sorry for the delay!

ROTFL in both amusement and appreciation. 9:49-10:56 ... on a Sunday night. Brilliant.

If I get IT support even half this good in my new job I will be one VERY happy person!

[Yurt]

I hadn't seen these posts but I was looking at a frog map this morning and noted the icons popping up. Just had to consider if they read right to left or left to right!
Great idea and implementation.

[blossom*]

Stunningly, amazingly BRILLIANT!!!!!!!!!!

[gmj3191]

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

Hundreds of apps feeding off GCA?

Well there's one we know of, and the developer of that one is already involved in this discussion.

Are there others, and who supports them? It would be good to have this information anyway.

[mtrax]

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

Hundreds of apps feeding off GCA?

Well there's one we know of, and the developer of that one is already involved in this discussion.

Are there others, and who supports them? It would be good to have this information anyway.

perhaps if this is the major issue we can send this information only to GCA apps or just displayed on the website.
ie create a new LOG type of "found and Taken" and only expose this to apps which explicitly request it eg GCA Cacher and the website.

I see the Moved log type doesn't appear in my GPX file so can this "Grabbed" log type be treated the same way? or converted to Note log type

[caughtatwork]

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

Hundreds of apps feeding off GCA?

Well there's one we know of, and the developer of that one is already involved in this discussion.

Are there others, and who supports them? It would be good to have this information anyway.

No. Hundreds of 3rd party apps that read GPX files. They read the GPX file believing that the only place in the world that produces them is GC.com. They then parse the GPX file according to their ability and knowledge of the GC.com GPX schema. So anything that comes in a GPX file that is NOT in the GC.com GPX schema causes various problems either by failing nicely or failing catastrophically.

If you had an app that read only the GC.com GPX schema and loaded a GCA file into it and the app developer didn't know what they were doing and the GPX file parser crashed your device, so it wouldn't recover, you probably wouldn't be pleased.

Unfortunately, we are stuck behind the big fish in this regard and creating custom logs and other tags in the schema means most apps will fail. You may have read that GC.com has been looking at deploying a nano cache size for a long time (possibly 12-18 months), but they can't do it (easily) as 3rd party apps cannot handle the value of "nano" in the cache size tags. They created a rod for their backs and ours by having a poorly enumerated schema which means people looked for "possible values" and hardcoded them in, rather than enumerating the values in the schema which the app could then parse automatically.

[caughtatwork]

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

Hundreds of apps feeding off GCA?

Well there's one we know of, and the developer of that one is already involved in this discussion.

Are there others, and who supports them? It would be good to have this information anyway.

perhaps if this is the major issue we can send this information only to GCA apps or just displayed on the website.
ie create a new LOG type of "found and Taken" and only expose this to apps which explicitly request it eg GCA Cacher and the website.

I see the Moved log type doesn't appear in my GPX file so can this "Grabbed" log type be treated the same way? or converted to Note log type

GPX files, not just real time apps.
If I stuck in a "grabbed' log, what would GSAK do? What would neon-geo do? What would c:geo do?
It's very nice to say we could just create a new log type, but if your favourite app then stopped working because of the GCA specific values and crashed your device, you would not be happy.

We could change "grabbed" to "noted". That puts you in the same position now. You have a "found" as the last log so you need to read it to see if the cache has moved. If you have a "noted" as the last log, you would need to read the log to see of the cache has moved. Same problem, different log type.

As I mentioned before, the site can handle this. Other apps can't. As I also mentioned before, you are now forcing people to log in a certain way which is pretty much not on. Found, grabbed, "in transit", moved whereas I can do all of that now with a "found" log. One step versus 3 or 4 logs. So every cacher would be putting up 4 logs (3 or what, whatever), just to make it easier for those who are too lazy to read the last log. That would also force a cache to be "found" again, which I don't want. I want the fun on moving it on, but not having it count as an additional find. Forcing logs would take away that capability.

[blossom*]

[quote="caughtatwork]............. a poorly enumerated schema which means people looked for "possible values" and hardcoded them in, rather than enumerating the values in the schema which the app could then parse automatically.[/quote]

Yeah, I was going to explain that technical detail

[caughtatwork]

Sorry, but this is why sometimes you need to trust your developers. We work in a complex, technical environment. It's hard for the layperson to understand why we can't do something. It all seems to easy until you look at the details and then it becomes hard.

This is the GC schema.
http://www.groundspeak.com/cache/1/0/1/cache.xsd
This is the container.
<xs:element name="container" msdata:Prefix="groundspeak" type="xs:string" minOccurs="0" msdata:Ordinal="4"/>
There are no values enumerated. So it can contain literally anything. So in order to get a container and map it to a description (for an icon or something), you need to guess what possible values there could be. eg. Small, Regular, Not Chose, Micro, etc, etc. So if GC introduce a "nano" size and the app owner has guessed what values there could be, a new value of "nano" which they don't cater for could cause problems.

This is the GCA schema.
http://geocaching.com.au/geocache/1/0/1/geocache.xsd
This is the container.
<xsd:element name="container" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Virtual"/>
<xsd:enumeration value="Nano"/>
<xsd:enumeration value="Micro"/>
<xsd:enumeration value="Small"/>
<xsd:enumeration value="Regular"/>
<xsd:enumeration value="Large"/>
<xsd:enumeration value="Other"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
GCA has enumerated the possible values, so the app developer simply uses the list provided. New values get enumerated in a new version of the file (say 1.0.2, 1.0.3, etc). So if the apps gets a 1.0.1 file, they get the 1.0.1 schema and use the values. If they get a 1.0.2 file, then get the 1.0.2 schema and use the vales. No guess work required for the developer.

So if the app developer does not cater for "nano" (because they do a shitty job and expect only GC files), what do they do when they get a value they're not expecting? Fail? Abort? cater for it? Not all developers are made equal. Some will do a better job and handle the exception, others will simply fail.

So to use the same example for a log type, if we put in "Grabbed", the apps that parse the file according to the schema version at GCA will be fine. The apps that are looking for only the GC log types may work, may fail, may abort, god only knows what.

Given there are hundreds of apps that parse GPX files, most of them done by non-professionals, most of them would simply fail. Possibly very poorly.

I hope that helps to understand the technical nature of the reason for not just creating new values and "hoping" everyone can cope. They can't.

[blossom*]

I hope you didn't take my earleir comment as a request for more techincal detail I did actually get the gist of what you said before (and was trying to be funny ) and I totally trust you to know what can be done and what can't. I think most others here do too, you guys are always great at doing anything that is possible really quickly wherever it makes sense.

[caughtatwork]

Nah, that's cool. Questions help everyone understand just a little bit more than even though computers can do lots of things, developers don't always cater for the unexpected which means sometimes you just have to accept that status quo.