New cache attributes?

[andrixnet]

Last year GC has added 4 new attributes:

1. Bonus cache
2. Power trail
3. Challenge cache
4. Has solution checker

I propose taking into consideration OC equivalents, first of all as a discussion and maybe later as an implementation.

• Bonus cache - likely meant as a bonus for a mystery series, a power trail or other situation. OC does have GeoPath and a cache type "geopath final" the state of which is uncertain (it reused the type id of the former "MP3 podcast cache") or deprecated (?) _Anyway, "Bonus cache" as attrib doesn't necessarily only mean the bonus of a GeoPath. It can also be a bonus to some challenge(s) (?) Recommend Geopath Final / MP3 podcast as cache type be scrapped.

Either use it only for Geopath bonus, then it is set by system only. Or use it to represent as a generic bonus indicator, user can set it, setting a cache as Geopath bonus automatically sets attrib._

• Power trail - in OC lingo "GeoPath". Cache belongs to [at least] a geopath. While this is proeminently shown on the website, it ends there. Now with this attribute in common, OC could export this information as attribute to third party apps, like c:geo and allow in-app searching and filtering. This attribute should not be user settable (same as password attrib) and the system sets this attribute automatically once the cache becomes part of at least one geopath.

According to further discussion, GeoPath attribute should not reuse GC "Power trail" ID.

• Challenge cache - this is actually part of the OCNA requested cache_type, already implemented, not yet deployed (PR awaiting review). With this in mind, I invite OCNA representatives to reconsider their type request. Challenge attribute implemented already at OCNA. (2021) user settable.

• Has solution checked - OC had Openchecker long before GC implemented their own solution (player relied on things like the external geochecker). This could become a special attribute, not directly settable by user, in a similar way to "has password" attribute. User checks "openchecker" for the cache, the system automatically assigns the "solution checker" attrib to the cache and vice-versa. Not shown in list of user settable attribs. Shown in search page. Again, this has the advantage of exporting to third party apps the info/flag/attrib making possible to search/filter by this criteria

I propose that:

• opencaching-pl takes into consideration these attributes for possible implementation, including particulars, on the principal grounds of improved third-party app interoperability
• individual OC sites take into consideration if they want to activate such attribs or not and ammend their rules/docs accordingly

Note: given the current state of the code - attribute implementation 95% in the database, practically each site can de-facto add these as simple attributes however they choose to. The purpose of this issue listing is to provide the framework for a unified implementation.

opencaching

[rapotek]

Just one remark: geopath is NOT a power trail. While I do not like current geopath functionality because of its limits, I know that our geopaths are various in topics, often contain many cache types, sizes, D/Ts etc. Power trails, however, are rarely more than a bunch of identical, common, cheap caches set in purpose of make possible to easily improve statistics of finds. Even the attribute description in GC says that:

A geocaching power trail is a large number of caches, often placed at minimum distance (0.1 miles, 161 meters) to each other, hidden along a walking, biking, or driving route. It often promotes a player’s ability to easily increase their find count.

I have a feeling that using the same attribute for our geopaths, while convenient is somewhat degrading for them and can be misunderstood when an application showing the same attribute for caches from different geacaching sites uses its GC name and description.

[andrixnet]

@rapotek: A valid point. Technically it also can be a new, different attribute ("geopath attrib") - for the purpose of enhancing third party app interraction and data, or none at all.

[andrixnet]

See updated description.