search

opencaching / gpx-extension-v1

Opencaching GPX extension schema
3 stars 2 forks source link

Adding an OC size element #5

Open following5 opened 7 years ago

following5 commented 7 years ago

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

(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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

320 87

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 commented 7 years ago

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

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

nano micro large verylarge

Result:

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 commented 7 years ago

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 commented 7 years ago

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

nano micro large verylarge

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

andrixnet commented 7 years ago

https://github.com/opencaching/okapi/pull/511#issuecomment-330181872

I saw this thread after posting the above.

andrixnet commented 7 years ago

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 commented 7 years ago

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:

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

wrygiel commented 7 years ago

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 commented 7 years ago

79074fb, cf95c16

following5 commented 7 years ago

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.