Page 1 of 1
Stats request - Finds on CCE events
Posted: 29 November 22 11:13 pm
by Laighside Legends
There is currently this graph for finds on events:
https://geocaching.com.au/stats/cachers ... inds_event
And there are similar ones for CITOs and megas.
Would it be possible to have a CCE event one?
Re: Stats request - Finds on CCE events
Posted: 30 November 22 7:25 am
by caughtatwork
Re: Stats request - Finds on CCE events
Posted: 30 November 22 10:24 am
by Laighside Legends
caughtatwork wrote: ↑30 November 22 7:25 am
Sorry, I don't know what a CCE is.
Community Celebration Events, eg:
https://coord.info/GC9NVQQ
https://coord.info/GC8K142
https://coord.info/GC8HMM6
Re: Stats request - Finds on CCE events
Posted: 30 November 22 11:56 am
by wayn0
Community Celebration Events are a newish subgroup of the Event cache celebrating milestone years of geocaching.
https://www.geocaching.com/blog/2019/12 ... on-events/
Re: Stats request - Finds on CCE events
Posted: 30 November 22 3:17 pm
by caughtatwork
Thanks.
The GPX file has a type of
<type>Geocache|Event Cache</type>
This doesn't allow us to split from any normal Event Cache.
Sorry, we can't help with that statistic unless the GPX file contains the unique cache type.
Re: Stats request - Finds on CCE events
Posted: 06 December 22 3:06 pm
by Laighside Legends
I looked a bit more into this and it appears they do have a different type when using Groundspeak's API but not with their GPX files, which would be why ProjectGC recognises them as a different type.
With GSAK, you get different results depending on if you use the API or the GPX importer. Which is a bit annoying.
But no one seems to have mentioned this inconsistency in Groundspeak's forum which seems a bit odd (and the GSAK forum just has a post acknowledging the inconsistency, since there's not really anything GSAK can do about it anyway)
Re: Stats request - Finds on CCE events
Posted: 07 December 22 8:36 am
by caughtatwork
Groundspeak made a small rod for their own back by enumerating their cache types in the XSD. What that essentially did (and I understand why they did it), is that when poorly written importers of GPX files use the XSD, they don't handle any exceptions. So a new cache type would need a new XSD version and all of the challenges that come with that.
A while ago they changed the name of the the Mystery cache (possibly to Mystery / Unknown or something like that). That instantly broke dozens and dozen of processors that use GPX files as they could not handle anything that was not enumerated. It was reverted the next day and they have never tried to update it again.
This simply means that new cache types are difficult to get out in a GPX file as, technically, without a new XSD the file would fail validation.
It's a shame that it's all done this way, but not much we can do about it. If they allowed access to the API, then we wouldn't have this sort of problem, but that's another story for a long and dark day
