Adding an OC size element

[following5]

I think that the following OC geocache properties are worth to be added to GPX:

• Mandantory properties:
  • type - the types 'Moving' and OCPL-'Podcast' are lost when mapping to GS types
  • size - the sizes 'very large' and OCDE-'nano' are lost when mapping to GS types
• Optional properties:
  • other platform cache code, e.g. GC code (maxOccurs > 1)
  • trip time
  • trip distance

(Additionally the OC types "Drive-In" and "Maths/Physics" are lost, but they are not important and should be discontinued anyway.)

I don't see any of these properties in GSAK or c:geo namespaces.

I have changed the topic from "Adding more OC elements" to "Adding an OC size element." For discussing other new elements, please use separate issues!

[wrygiel]

A.d. "size" - OX defines a size scale (1.0-5.0). Might be possible to reuse this. Depends on how exact a mapping can be defined.

[following5]

Oh, the OX extension is not in the article yet. :-)

Right, ox:size even is already implemented in OKAPI. If OX namespace is included, it will map all the OC sizes to some OX sizes. But practically I think ox:size is dead. Cachers don't know it, developers don't know it, apps don't undestand it, geocaching websites don't support it in any way, except for the OKAPI option.

The chance that developers support the OC sizes should be better with an oc:size which extends the well-known groundspeak:container.

[wrygiel]

Garmin devices support it. I don't know about any other apps, but simply saying that "Garmin devices support it" is a good way of promoting it. It's almost impossible that Garmin devices will ever support our own namespace, and millions of people use Garmin devices.

[following5]

I have created some sample GPX files with different oc:sizes and posted them in the OC.de forum. Let's see what different Garmin devices make of it, and if it's useful at all! What they cannot do is display what geocachers know and expect - "nano" or "very large".

Another issue about ox:size is that it cannot handle "Other size", so developers would need to evaluate two size fields.

And, as you already mentioned, there is the mapping issue. Besides of promoting OX namespace, we would also need to establish some mapping groundspeak:container/OC-Size <-> ox:size as a standard. If we don't succeed, groundspeak:container -> ox:size -> groundspeak:container may change the size if different applications are involved. So there is some risk for developers when supporting ox:size.

What I cannot imagine is that any of today's geocaching databases will ever store sizes in OX type. If someone goes for a numeric size, I think it will be some rounded (milli)litre values, because really every user intuitively undestands that, and there already exists some consensus about mapping between litres and groundspeak:container.

---

Btw., just now a OC.de user requested to add the GC code to OC GPX files. :)

[following5]

This is what a Garmin GPSmap64 makes of ox:size=4.7 (large) and oc:size=1.3 (nano), created by OKAPI with ns_ground=true&ns_ox=true:

It does not display the ox:size, but tries to map it to groundspeak:container and then displays it in GC.com style. If it does not succeed - see the Nano cache on the right hand - it does not display a size at all.

The example files for micro (ox:size=2.0) and very large (ox:size=4.9) were not accepted by the device. But this were four different caches, so the rejection probably is not related to the sizes.

[following5]

Here are the results for a Garmin Oregon450 for the same GPX files, from left to right:

• OCDE Nano, GC Micro, OX 1.3
• OC Micro, GC Micro, OX 2.0
• OC Large, GC Large, OX 4.6
• OC Very large, GC Large, OX 4.9

It accepted all four files. This is in Swiss-German, "Grösse" = size, "Gross" = large:

Result:

• OCDE Nano => no size
• OC Micro => Micro
• OC Large => Large
• OC Very large => Large

Since OpenCaching.com has been discontinued, Garmin is cooperating with Groundspeak. Obviously they don't see any more sense in bothering users with their own ox:size.

[following5]

The example files for micro (ox:size=2.0) and very large (ox:size=4.9) were not accepted by the device.

This is very likely not connected to OX data in the GPX. The files are also rejected without OX data, and this device is generally picky about the GPX files it accepts.

[following5]

Uh... these two devices were too old! Here is the result of an eTrex 30:

Size numbers are displayed, and they even name the "nano".

[andrixnet]

opencaching/okapi#511 (comment)

I saw this thread after posting the above.

[andrixnet]

IMO, since Garmin has closed opencaching.com and cooperating with Groundspeak instead, the OX standard/namespace/whatever is dead anyway. As said above, nobody but [some of] Garmin's own devices have any support for it, but then falling back to a Groundspeak-1.0.1 equivalent is much easier and a much better idea for compatibility anyway.

Besides, I am not sure about Garmin's trend, but in Oregon 550 they had Groundspeak's WHERIGO player which was removed in the Oregon 650. I don't have access to an Oregon 7xx but somehow I doubt it's back.

[following5]

And noone knows if tomorrow Garmin devices and firmware versions will still understand OX namespace. The eTrex 30 - as I meanwhile found out - has three display modes:

• "Auto": This is equivalent to the Oregon450 example above and probably the default. ox:size is useless here.
• "OpenCaching.com": This is the eTrex 30 example above, ox:size is displayed.
• "Traditional": ox:size is ignored.

How long will they retain the "OpenCaching.com" mode, with no more OpenCaching.com?

[wrygiel]

True, if Garmin is planning to drop support to OX namespace from their own future devices, then OX namespace is dead indeed.

Either way, we may introduce our own alternative, I guess. This shouldn't hurt anyone.

I must admit that I really liked Garmin's 1.0-5.0 approach to attributes. It was just incredibly clear and flexible. Attributes used in GC and OC are not that much flexible, and I'm a little afraid that more size-values might be added to OC in the future (and this would require us to introduce another element, etc.). It's a pity that OX schema dies.

[following5]

79074fb, cf95c16

[following5]

Copied from this discussion:

@andrixnet:

The only other size value that might be added and makes sens would be "not specified" (cache owner intentionally does not want to specify the size of the container as part of the difficulty)

Yep. It already exists, we can add it to the docs:

GC "Not chosen"
GC API "N"
OC.RO 1 = "Not specified"
OKAPI: (we missed this when defining size2!)

I think "Not specified" is more precise than "Not chosen", but for GPX so far we try to stick with GS as closely as possible Therefore I suggest to add it as "Not chosen" to the GPX extension annotations.