New cache types

[+Bo_Jack]

Just was wondering if HQ ever plans to make a new cache type.

[RuideAlmeida]

18 minutes ago, Bo_Jack said:

Just was wondering if HQ ever plans to make a new cache type.

 

Sure... the next one will be Community Celebration Event, by instance.

[+TeamRabbitRun]

52 minutes ago, Bo_Jack said:

Just was wondering if HQ ever plans to make a new cache type.

 

Just wondering, as you said, or did you want to suggest something.

[+Bo_Jack]

15 minutes ago, TeamRabbitRun said:

 

Just wondering, as you said, or did you want to suggest something.

Nope was just wondering. Since I’ve started caching, which was just 2017 by the way, I didn’t think any new ones have been made. But I guess community celebration is new.

[+Lynx Humble]

1 hour ago, RuideAlmeida said:

 

Sure... the next one will be Community Celebration Event, by instance.

Technically it's the 'Lost and Found' type for the 10 yrs they are reusing.

 

17 minutes ago, Bo_Jack said:

Nope was just wondering. Since I’ve started caching, which was just 2017 by the way, I didn’t think any new ones have been made. But I guess community celebration is new.

I started in 2015 and since then I only saw the reintroduction of the virtual and the lab cache (adventure) but you have to be chosen by Groundspeak. There are also the one locationless but it's so limited that I don't count that.

 

Personally I would love to see a Challenge cache type introduced.

[+TeamRabbitRun]

Realize that it's not a simple thing to do.

 

In addition to their own database, website and phone applications, Groundspeak provides an API, an "Application Programming Interface", to other companies as an authorized, supported method of interacting with their system.

 

So, unless a tremendous amount of forethought was put into this API when it was designed and built by Groundspeak, AND by the companies USING it, changes to the system, like new cache types, may break it.

 

Lots of coordination - getting EVERY API partner on board and giving them enough lead time to change their applications. And, if they DON'T make the changes, who gets the blame? Right.

 

Other agents out there also access GS' data, for example through screenscraping, but unless they're an authorized API partner, tough luck.

 

There are also essentially HARDCODED interfaces, like the one in my Explorist GC that can't be updated. What would happen if I tried to display a new cache type? Don't know! Who knows how the programmers allowed or didn't allow for that. Maybe it would explode! THEN, I could justify a new one!

 

Good and bad there; a friend just 3D printed a bicycle mount for my Explorist. The commercially-available ones out there are like, forty bucks! I'd HATE to see his effort wasted. But, I digress.

 

The same issues exist with new attributes, as well.

 

So, lots to think about before we seriously suggest a new cache type. I think they did a pretty good job laying out the types. Every time someone suggests another one here in the fora, we've figured out that the "new-must-have" type actually fits in pretty well already.

 

The point is, you can have all kinds of caches of different types (lower-case "t"), but unless the game is going to treat it differently, with special rules, then it's most likely really one of the existing Types ("upper-case "T") and can be differentiated in other ways, as had happened with Challenge Caches.

Edited April 1, 2020 by TeamRabbitRun

[+thebruce0]

GPX have version numbers, so presumably and hopefully devices take version into account. One idea would be to create a new GPX version number which includes the new type, and for backwards compatibility provide the new cache type as an existing one (such as the catch-all Unknown). Old devices would continue to work, cachers would by then be made aware of the new cache type and issue with old hardware that won't be updated, and anything that can be updated will continue to work until implementing the new GPX version; API partners (afaik) are pretty much required to keep up to date. Even if not, same applies regarding backwards compatibility.   Any stats generation (eg PGC) would obviously use the latest data structures.

(just some thoughts; not advocating for/against a new cache type, just looking at some technicalities :))

[+JL_HSTRE]

Since Letterbox Hybrids were introduced in 2006(?) we have only got two new non-event cache types: Wherigo and Lab. And both use a separate app (although Lab didn't initially). And if Groundspeak could do it over Letterbox would be an Attribute, not a cache type.

 

The lack of a separate Challenge cache type suggests to me that Groundspeak is really trying to avoid introducing any new types. 

[+frinklabs]

15 hours ago, JL_HSTRE said:

The lack of a separate Challenge cache type suggests to me that Groundspeak is really trying to avoid introducing any new types

 

There's no need for a new cache type for Challenges.  

Any needed functionality could be provided through implementation of a system that would only require a new rating attribute and log type.

For a Challenge cache type to work, it would need the additional log type or else you are back to pounding square pegs into round holes with post ipso facto log-type alterations which render your stats meaningless.

[+NYPaddleCacher]

17 hours ago, thebruce0 said:

GPX have version numbers, so presumably and hopefully devices take version into account. One idea would be to create a new GPX version number which includes the new type, and for backwards compatibility provide the new cache type as an existing one (such as the catch-all Unknown). Old devices would continue to work, cachers would by then be made aware of the new cache type and issue with old hardware that won't be updated, and anything that can be updated will continue to work until implementing the new GPX version; API partners (afaik) are pretty much required to keep up to date. Even if not, same applies regarding backwards compatibility.   Any stats generation (eg PGC) would obviously use the latest data structures.

(just some thoughts; not advocating for/against a new cache type, just looking at some technicalities :))

 

First,  I am an api developer so am pretty familiar with this kind of stuff.

 

If the results from the API are based on the GPX (which would make sense) then looking at the GPX schema extensions that Groundspeak has created would determine if a version number is required.  In this case, the type element is defined as "xs:string" which mean that the element can contain *any* string, not just the official cache types and means that if Groundspeak created a new cache type, that using "Challenge" (or any other string) would be valid.  Clients which assume that type element can only be one of the existing cache types, and break if it is something else, are flawed and it's not Groundspeaks fault if they're not complying with the schema.

[+mustakorppi]

The current API even has a function to get all known geocache types. So API partners could, if they had the resources and motivation, make their systems support arbitrary new cache types automatically*. Not sure if anyone has actually bothered but they could. The only gotcha for API partners I can think of is if they need to have a localized name for cache types. 
 

Devices dealing with GPX files have the same problem, in addition to not having an icon to show for the new cache type. That might be a problem if literally zero effort was made to work around these entirely foreseeable issues. Changing the schema, on the other hand, definitely would break offline devices that actually bother to try and validate the XML.

 

* There’s an appreciable difference between a system that can handle a new cache type without breaking, and a system that will also automatically populate its user interface to show the new cache type in places like search filters etc.

[+dprovan]

57 minutes ago, NYPaddleCacher said:

First,  I am an api developer so am pretty familiar with this kind of stuff.

 

If the results from the API are based on the GPX (which would make sense) then looking at the GPX schema extensions that Groundspeak has created would determine if a version number is required.  In this case, the type element is defined as "xs:string" which mean that the element can contain *any* string, not just the official cache types and means that if Groundspeak created a new cache type, that using "Challenge" (or any other string) would be valid.  Clients which assume that type element can only be one of the existing cache types, and break if it is something else, are flawed and it's not Groundspeaks fault if they're not complying with the schema.

But GS recognizes that such mistakes will be more common than not. And they know they'll get blamed even though it isn't their fault.

 

I only looked casually at the GPX schema a long time ago, but it left a lot of room for interpretation. As I recall, it was things like, as you say, having an open ended string field, but then saying "It can only be this, this, or this," and not talking about what it would mean to have an unexpected value. And that's not particular dumb or anything: it's one thing to say a developer should expect an arbitrary cache type name, but it's another thing for future proof code to be able to handle an arbitrary new cache type. There's more to a new type than just its name. That's why someone would want a new type, right?

 

I don't mean to take any particular stand on new cache types, I'm just very sympathetic to the technical difficulties, especially when GS only defines the interface but doesn't control the software. From my experience, it's hard enough to deal with this kind of change when you can rev all the software yourself because even when you have perfect software that deals with the new cache type, your old existing code out in the field that doesn't know about it will be used forever.

[+frinklabs]

Any API programmer working from fixed lists where there's a call to get a list of elements is weak.
 

One of the differences between the schemas relates specifically to cache types, where the old method was a fixed list (enum) of types.   They fixed this by creating a unique field type called Type, a list of which you can get with its GetGeocacheTypes API call.    

The list of Log types is extensible and can be retrieved with the geocachelogtypes API method.  

 

You would need these additional extensions to the schema and API -- simply adding a new cache type does not address the issues that exist around the way Challenges are currently (mis)handled.   

Specifically around the chewing-gum-and-baling-wire "solution" for allowing pre-signing of Challenge cache physical logs.  

Which would be fixed with implementation of features that bifurcated the Find from the Challenge completed events. 

[+mustakorppi]

6 minutes ago, dprovan said:

There's more to a new type than just its name. That's why someone would want a new type, right?

The interesting stuff is just text/html in the description. It’s not like you need to build your own Wherigo player to interact with a gpx file that describes a Wherigo cache. 

[+The Jester]

13 minutes ago, frinklabs said:

Any API programmer working from fixed lists where there's a call to get a list of elements is weak.
 

One of the differences between the schemas relates specifically to cache types, where the old method was a fixed list (enum) of types.   They fixed this by creating a unique field type called Type, a list of which you can get with its GetGeocacheTypes API call.    

The list of Log types is extensible and can be retrieved with the geocachelogtypes API method.  

 

You would need these additional extensions to the schema and API -- simply adding a new cache type does not address the issues that exist around the way Challenges are currently (mis)handled.   

Specifically around the chewing-gum-and-baling-wire "solution" for allowing pre-signing of Challenge cache physical logs.  

Which would be fixed with implementation of features that bifurcated the Find from the Challenge completed events. 

Sigh.  As if you "solution" doesn't have as much or more programing (from my experience, more) work to add to the API/GPX.  But I must say, you are consistant (and persistent IMO).  But let's not derail this thread with that discussion (again).

[+JL_HSTRE]

On 4/7/2020 at 11:53 AM, frinklabs said:

There's no need for a new cache type for Challenges.  

 

Challenge Caches have a very unique feature: they are the only geocache you can find and sign the log, but not necessarily log a Find.

 

Also, other than Challenge Caches, most Unknowns/Mystery do not have their Final at the posted coordinates. Especially since "puzzlebox" field puzzles at the posted coordinates are usually published as Traditionals (I think that's wrong, but it's currently the reality).

[+Isonzo Karst]

On 4/6/2020 at 8:22 PM, JL_HSTRE said:

Since Letterbox Hybrids were introduced in 2006(?) we have only got two new non-event cache types: Wherigo and Lab

 

LBH were part of the original types dating from Spring 2001.  The last new type created that a player can select on a cache report is Wherigo,  2008.  Prior to that were CITO (2003) and Earthcache (2004).

As to a new type that a player can select from a pull down on the cache report, seems unlikely. 

 

[+thebruce0]

And sure, updating a version number can be relegated to schema changes, but it can be used as a sort of fresh start. To not have to worry at all about breaking hard coded devices however well or badly they were programmed, a new GPX version can address a multitude of problems with the data content and/or schema structure, and even make values like cache types much more dynamically determined. But I think the API is really where HQ wanted to move - not static GPX version increases.  But I don't think it would be a bad thing to come up with just one more proper GPX version that provides that raw offline data export which can be made flexible and future-proof while allowing the API to be the more active and dynamic interface now that most devices are effectively online or have wifi abilities to make use of the functionality (and be kept up to date)

[+mustakorppi]

1 hour ago, thebruce0 said:

To not have to worry at all about breaking hard coded devices however well or badly they were programmed, a new GPX version [...]

What do you think old devices are going to do when you try to import an XML file using a schema they do not recognize?

 

I can think of two things: either they try to validate the file, fail because they don’t have the correct schema to validate it against and refuse the file, OR they dont’t validate, don’t care about the schema version number and just import on their old assumptions of what a geocaching GPX file is like.

 

Typing out that last sentence reminded me that geocaching GPX file doesn’t need to originate from GS, and that a prominent GPSr manufacturer hosted its own platform not all that long ago.

[+thebruce0]

40 minutes ago, mustakorppi said:

What do you think old devices are going to do when you try to import an XML file using a schema they do not recognize?

That's what "new GPX version" means.  If it's hard coded for a specific version number, then it can only understand that version. A new GPX version number means one should not provide that version to a device that can't understand it (that's up to the user), unless the device programmer was smart enough to check the GPX version when loading (that's up to the device). You don't update an old version yet keep the same version number in the data file.  GPX 1.0 contains data and structure valid for 1.0. GPX 1.1 contains data and structure valid for 1.1.

 

41 minutes ago, mustakorppi said:

I can think of two things: either they try to validate the file, fail because they don’t have the correct schema to validate it against and refuse the file,

It should check the GPX version (part of the standard schema) when it loads the file. If it doesn't like the version number, it should deny the file. If it doesn't check the version, its user should (or will) know that it can't accept that GPX version, and not download it. That's why version numbers are important.

 

 

[+barefootjeff]

10 minutes ago, thebruce0 said:

It should check the GPX version (part of the standard schema) when it loads the file. If it doesn't like the version number, it should deny the file. If it doesn't check the version, its user should (or will) know that it can't accept that GPX version, and not download it. That's why version numbers are important.

 

We already have the option in our account preferences to select which of the current versions we want to use:

 

 

If a new version were to eventuate, it could just be added to the list and those with devices that support it could select it while those that don't can stick with their existing preference.

[+thebruce0]

5 minutes ago, barefootjeff said:

We already have the option in our account preferences to select which of the current versions we want to use

Exactly

[+mustakorppi]

8 hours ago, thebruce0 said:

That's what "new GPX version" means.  If it's hard coded for a specific version number, then it can only understand that version. A new GPX version number means one should not provide that version to a device that can't understand it (that's up to the user), unless the device programmer was smart enough to check the GPX version when loading (that's up to the device). You don't update an old version yet keep the same version number in the data file.  GPX 1.0 contains data and structure valid for 1.0. GPX 1.1 contains data and structure valid for 1.1.

It’s not a matter of ”hard coding for a version number” it’s a matter of having the actual schema to validate against. An offline device needs to keep a local copy, and existing devices obviously cannot contain a file that does not yet exist.

 

No new data structures have been proposed, just a new value for cache type. That is perfectly valid for GPX 1.0. If you don’t allow new cache types in GPX 1.0, you are blocking the new cache types from all devices that no longer receive updates, regardless of whether they could actually support it. If you allow the new cache type in both GPX 1.0 and the new GPX version, what’s the use of the new version?

 

If it turns out there are devices that can’t handle GPX files where the cache type is “Awesome new cache type” instead of one of the old ones, it would be far more useful to provide an export filter which maps new cache types to “Unknown” and appends the real cache type to description (or as one of the included logs). I.e. what third party sites are already doing to include things like favorite points of the cache.

[+thebruce0]

On 4/10/2020 at 9:48 AM, mustakorppi said:

No new data structures have been proposed, just a new value for cache type. That is perfectly valid for GPX 1.0

I know, that's why I said in a prior comment that even though a structure may not change, it could be worth putting up the new version anyway, because then old devices using the old version can continue to trust even the values improperly hard-coded and assumed, while the new version can provide new values without breaking things. Making a new version ensures that for whatever reason, every device using the old version will not get anything 'new' that might mess with their (improperly) hard-coded handling to structure and data.

 

On 4/10/2020 at 9:48 AM, mustakorppi said:

If you don’t allow new cache types in GPX 1.0, you are blocking the new cache types from all devices that no longer receive updates, regardless of whether they could actually support it. If you allow the new cache type in both GPX 1.0 and the new GPX version, what’s the use of the new version?

If a device is properly coded but hard-coded to GPX 1.0 and will not receive updates, that's already an issue. As mentioned in a prior comment, new cache types can still be provided to the old version in a fallback manner, such as using the catch-all Unknown cache type. I mean how do those old devices handle these new sub-types already being used like Community Events? There are exceptions as well like GCHQ; GSAK had to do the same for stats generation, by text-matching the cache name (iirc) to track those exceptions to cache types so they'd be reflected in stats. ..but those scripts can get updated.

Knowing officially that the "Mystery" type is a catch-all, new cache types can be added to geocaching proper, and GPX 1.0 can support them - if they're sent as the Mystery (or some other) cache type (and yes that's a drawback for devices that are hardcoded to GPX 1.0 and yet do understand a dynamic list of cache type values)

 

On 4/10/2020 at 9:48 AM, mustakorppi said:

If it turns out there are devices that can’t handle GPX files where the cache type is “Awesome new cache type” instead of one of the old ones, it would be far more useful to provide an export filter which maps new cache types to “Unknown” and appends the real cache type to description (or as one of the included logs). I.e. what third party sites are already doing to include things like favorite points of the cache.

Yes, that's what I've been saying, and that's already done - for backwards compatibility.

 

But for a proper GPX, I'm saying it is, in my opinion, feasible to provide a fixed GPX as a new version, a sort of finalized structure that resolves future-proofing concerns and so that it's expected that any device now being coded for it can be explicitly assumed to also understand any potentially dynamically changing content - structure OR data. But as of right now the API seems to be the direction hq is going. I am a web app developer, and perhaps it's OCD of me to feel like leaving a problematic data export format out in the open like that is itself a problem =P I'd want to 'wrap up' the GPX thing by providing a better version that addresses any current issues for any devices or software that wishes to continue using it (because the raw data export still has value), and then move on to the continued API development.

[+mustakorppi]

15 hours ago, thebruce0 said:

it could be worth putting up the new version anyway, because then old devices using the old version can continue to trust even the values improperly hard-coded and assumed, while the new version can provide new values without breaking things.

If you have an old device that:

• validates the XML it receives
• only supports a hardcoded set of values arbitrarily decided by the device manufacturer in a cache type element
• does not validate the contents of that element before processing them
• does not process only the expected values and ignore everything else
• breaks in a bad way when it reads an unexpected value

then and only then will your solution help. If a device doesn’t do step 1, your solution doesn’t do anything and the device still breaks. If a device doesn’t do any one of the remaining steps, your solution isn’t needed. Now consider how likely the above is on a device built to read XML files coming in from arbitrary sources.(There are other geocaching sites. There are other sports that use GPX files.) Now consider the very real downsides of your solution.

 

15 hours ago, thebruce0 said:

If a device is properly coded but hard-coded to GPX 1.0 and will not receive updates, that's already an issue.

As has been already explained to you, GPX 1.0 already explicitly supports arbitrary cache types. It is not an issue, unless the device does something stupid. By forcing a new schema, you are obsoleting old devices that did everything right.

 

15 hours ago, thebruce0 said:

new cache types can be added to geocaching proper, and GPX 1.0 can support them - if they're sent as the Mystery (or some other) cache type (and yes that's a drawback for devices that are hardcoded to GPX 1.0 and yet do understand a dynamic list of cache type values)

GPX 1.0 does not require you to send new cache types as Mystery. You are arguing for a solution to a problem that doesn’t exist.

 

15 hours ago, thebruce0 said:

But for a proper GPX, I'm saying it is, in my opinion, feasible to provide a fixed GPX as a new version, a sort of finalized structure that resolves future-proofing concerns and so that it's expected that any device now being coded for it can be explicitly assumed to also understand any potentially dynamically changing content - structure OR data

But you are not resolving anything. All you’re doing is bumping the version number and expecting device manufacturers to magically stop being silly (assuming they were being silly in the first place, which you’re not even bothering to investigate). I’m not seeing anything that would prevent someone from making this exact same argument again the next time someone wants a new cache type.

[+geocat_]

I don't really see the need for a new type of cache.  To the OP, I know you said you don't have an idea for what type would be introduced, but just for fun, what type could you imagine being introduced?

[+thebruce0]

5 hours ago, mustakorppi said:

21 hours ago, thebruce0 said:

it could be worth putting up the new version anyway, because then old devices using the old version can continue to trust even the values improperly hard-coded and assumed, while the new version can provide new values without breaking things.

If you have an old device that:

• validates the XML it receives
• only supports a hardcoded set of values arbitrarily decided by the device manufacturer in a cache type element
• does not validate the contents of that element before processing them
• does not process only the expected values and ignore everything else
• breaks in a bad way when it reads an unexpected value

then and only then will your solution help. If a device doesn’t do step 1, your solution doesn’t do anything and the device still breaks.

 

Nothing will help that device. We can't care about those devices. Doing nothing doesn't help anyone. Doing something doesn't even affect those devices. So I'm no interested in any help for those ones.

And once again, a new version is an optional provision by the user of the website and device owner. One is not required to use a new version, let alone if they know the device can't handle it. Human factor.

 

5 hours ago, mustakorppi said:

As has been already explained to you, GPX 1.0 already explicitly supports arbitrary cache types. It is not an issue, unless the device does something stupid. By forcing a new schema, you are obsoleting old devices that did everything right.

There's already a 1.1, and there devices that only read 1.0, or can read them both. I I know what has been explained, no need to be condescending.  Anew version does not make past devices that will remain unaffected obsolete, until the version they support is removed entirely.  We've already had explained in this thread why simply adding new cache types is certainly not perfectly fine with current GPX across the board, even though some devices can handle new data.  And when the app/device has to hard code exceptions, that's not an optional solution.

 

5 hours ago, mustakorppi said:

GPX 1.0 does not require you to send new cache types as Mystery.

I didn't say it did. I said the data provider did so as not to break badly programmed devices/apps. That's a fact, as was evident with, as an example provided, stats generation in GSAK having to separate and make exceptions for specific caches to be treated as their own cache type when they were received as a standard, different type in the GPX.

 

5 hours ago, mustakorppi said:

But you are not resolving anything. All you’re doing is bumping the version number and expecting device manufacturers to magically stop being silly (assuming they were being silly in the first place, which you’re not even bothering to investigate).

You seem to be ignoring the examples of exactly what you're saying does not exist. And assuming I'm expected device manufacturers to change. No. I'm suggesting a final new version to add to the system that will provide a better, more optimal, flexible, data structure that can at once resolve issues with old version - without affecting currently devices that can't be updated to use it - and provide some closure to that export type in light of the fact that the API is the preferred and likely permanent manner of data export moving forward.

 

5 hours ago, mustakorppi said:

I’m not seeing anything that would prevent someone from making this exact same argument again the next time someone wants a new cache type.

Then don't suggest anything that would come to that. I'm not.  If nothing can be done, then don't do anything. But I fail to see anywhere in your argument that what I'm advocating for is somehow a Bad Thing.

[+mustakorppi]

1 hour ago, thebruce0 said:

I didn't say it did. I said the data provider did so as not to break badly programmed devices/apps. 

 

23 hours ago, thebruce0 said:

GPX 1.0 can support them - if they're sent as the Mystery (or some other) cache type (and yes that's a drawback for devices that are hardcoded to GPX 1.0 and yet do understand a dynamic list of cache type values)

It’s kind of hard to have a discussion like this.  
 

1 hour ago, thebruce0 said:

You seem to be ignoring the examples of exactly what you're saying does not exist.

I have have not said it does not exist, and you have not provided examples it existing. Your example was that GSAK has a hardcoded workaround for the GCHQ cache. Why? Because GS chose not to create a new cache type for it in GPX and codes it as a mystery instead. If you could show that was due to a verified issue with an existing device, you’d have something here. But I’d ask you to instead consider that GCHQ was published in 2004. If there was a known issue with introducing new cache types in GPX 1.0, how do you explain Earthcaches and Wherigo?

 

1 hour ago, thebruce0 said:

But I fail to see anywhere in your argument that what I'm advocating for is somehow a Bad Thing.

It’s extra work for everyone involved for little to no conceivable benefit. There are worse things in life, sure. 

[+thebruce0]

7 minutes ago, mustakorppi said:

2 hours ago, thebruce0 said:

I didn't say it did. I said the data provider did so as not to break badly programmed devices/apps. 

 

23 hours ago, thebruce0 said:

GPX 1.0 can support them - if they're sent as the Mystery (or some other) cache type (and yes that's a drawback for devices that are hardcoded to GPX 1.0 and yet do understand a dynamic list of cache type values)

It’s kind of hard to have a discussion like this.  

 

I don't know what you're trying to point out.

I did not say "GPX 1.0 requires you to send a new cache type as mystery."  GC HQ chooses to do so because Mystery is a catch-all, and so that these 'new' types can be understood, they do send them as Mystery. If they did not, then devices not programmed to understand such a 'new' type would break.

 

9 minutes ago, mustakorppi said:

I have have not said it does not exist, and you have not provided examples it existing.

 

I literally just did give one example.

 

9 minutes ago, mustakorppi said:

If there was a known issue with introducing new cache types in GPX 1.0, how do you explain Earthcaches and Wherigo?

 

Devices have been programmed to know the Earthcache and Wherigo cache types. GCHQ is an example of an exception that is treated as a type of cache. If they were to begin sending GCHQ as its own top-level cache type, devices without that hard coded as a cache type would not know what to do with it. it doesn't matter about when a type was made. It's the fact that if devices hard-code for specific values and do not allow for unknowns, they will break. And many devices have done that. And for any 'new' type HQ wishes to provide to the public, they need to be sent as Mystery or such devices will break. Others that are programmed to understand unknowns will not break if they did that. That is an outstanding, known, issue with the current GPX.  Let it be for all I care, I'm just discussing one possible option of how it can be 'fixed' moving forward.

 

13 minutes ago, mustakorppi said:

2 hours ago, thebruce0 said:

But I fail to see anywhere in your argument that what I'm advocating for is somehow a Bad Thing.

It’s extra work for everyone involved for little to no conceivable benefit. There are worse things in life, sure. 

 

Absolutely there are. But if we didn't discuss anything because "it's extra work" nothing would get done. Shooting an idea down merely because "it's extra work" is unproductive. Of course it's extra work. Many suggestions are. The valuation of whether it's worth doing the extra work is a different discussion. These are just ideas being tossed around in a forum. Neither of us work for HQ, so we can let them decide. I fully do not expect anything to happen with GPX versions. That doesn't mean I won't make any suggestions or chat about mine or other people's ideas.

[+NYPaddleCacher]

We had a similar discussion awhile back when some were suggesting adding "Nano" as a cache size, and the GPX specification similarly indicated that "size" could be any string.   I modified a GPX file, changing a cache size from "Micro" to "Nano" and sent it to my Garmin Oregon 450.  It displayed the cache size as Nano.   Typically, when a program expects one of several strings and it gets something it doesn't recognize it might display something which indicates that it doesn't recognize an expected response.  That's pretty basic programming.

[+mustakorppi]

1 hour ago, thebruce0 said:

I don't know what you're trying to point out.

 

1 hour ago, thebruce0 said:

GPX 1.0 can support them - if

There is no if about it. You implied the support is somehow conditional on specific workarounds. As you have since agreed, it is not.

 

1 hour ago, thebruce0 said:

Devices have been programmed to know the Earthcache and Wherigo cache types. GCHQ is an example of an exception that is treated as a type of cache. If they were to begin sending GCHQ as its own top-level cache type, devices without that hard coded as a cache type would not know what to do with it. it doesn't matter about when a type was made.

It kind of matters if you’re trying to use a specific type as an example of devices breaking, but new cache types of since been released apparently without incident.

 

1 hour ago, thebruce0 said:

It's the fact that if devices hard-code for specific values and do not allow for unknowns, they will break. And many devices have done that. And for any 'new' type HQ wishes to provide to the public, they need to be sent as Mystery or such devices will break. Others that are programmed to understand unknowns will not break if they did that.

Yes, though real world examples of affected GPSr devices have not been demonstrated. That aside, how does incrementing the schema version number help with this exactly?
 

1 hour ago, thebruce0 said:

That is an outstanding, known, issue with the current GPX.  Let it be for all I care, I'm just discussing one possible option of how it can be 'fixed' moving forward.

This is not so much an issue with GPX; you are describing something that is common to more or less all XML schemas and other data interchange formats as well. So if you have a fleshed out idea on how to create fully extensible data format, where devices that implement the format are guaranteed to understand arbitrary future extensions too, please share it with the world. Or if you have something with more limited geocaching application, that’d be interesting too.

 

 

[+thebruce0]

2 minutes ago, mustakorppi said:

There is no if about it. You implied the support is somehow conditional on specific workarounds. As you have since agreed, it is not.

I never changed what I've been saying. Perhaps I didn't make it clear. But I've changed no stance on anything.

 

2 minutes ago, mustakorppi said:

It kind of matters if you’re trying to use a specific type as an example of devices breaking, but new cache types of since been released apparently without incident.

Test it. Take a GPX, change the cache type to something gibberish. How does an old device handle it? Does everything about the cache work just as well as everything else? That's your test. 

 

4 minutes ago, mustakorppi said:

how does incrementing the schema version number help with this exactly?

I already explained the benefit of essentially beginning from scratch to address any and all outstanding issues without affecting prior hardware or code that won't understand a new version but will continue to work with the old. I know how XML works, and I understand how APIs work, as it is in my profession, both creating and using.

 

5 minutes ago, mustakorppi said:

So if you have a fleshed out idea on how to create fully extensible data format, where devices that implement the format are guaranteed to understand arbitrary future extensions too, please share it with the world. Or if you have something with more limited geocaching application, that’d be interesting too.

I didn't say I did, and I never suggested I had a better GPX schema. I was only ever suggesting that a new version would be beneficial to address any outstanding issues with the current GPX format by making some changes, improvements, even additions, without causing problems with old hard-coded devices and software that does not update, citing known issues (as insignificant as they may subjectively be) which are in comments in this thread. Even that the importance of such a change given the API is off and running is relatively small, at best. So?

If you simply don't think it's worth the time or effort, then that's just fine and dandy, we can leave it at that.

 

The whole point to this twig of a discussion was because in numerous past threads suggesting adding a new cache type, the GPX issues was a talking point. Creating a new cache type has ripple effects on many aspects of the geocaching system, including still-used legacy hardware that may not understand the new data if given in its proper form. Those devices will never get updated, they will always have to live with the risk of eventually breaking (inevitably, I'd say). Those can do get updated, can be updated to understand a new offline raw data export format, so why not implement that as a 'new and improved' gpx version, so it won't break legacy code, but it can provide an update for code that can understand.

That's all.

[+mustakorppi]

1 hour ago, NYPaddleCacher said:

It displayed the cache size as Nano. 

In all fairness, this could still lead to problems if the device supports multiple languages which includes translations for cache sizes. Handling a missing translation is also pretty basic programming of course, but if you have enough ”basic” things with a chance for error, well, we’re all human/canine.

 

But I think the most important part of this example is that these devices handle data which they get from the user instead of directly from a site like geocaching.com or ridewithgps or whatever.

[+ecanderson]

2 hours ago, NYPaddleCacher said:

We had a similar discussion awhile back when some were suggesting adding "Nano" as a cache size, and the GPX specification similarly indicated that "size" could be any string.   I modified a GPX file, changing a cache size from "Micro" to "Nano" and sent it to my Garmin Oregon 450.  It displayed the cache size as Nano.   Typically, when a program expects one of several strings and it gets something it doesn't recognize it might display something which indicates that it doesn't recognize an expected response.  That's pretty basic programming.

As a 450 owner, I'd be curious to know what you actually saw.  I assume this was a straight, unfiltered (by GSAK or whatever) load of a gc.com *.gpx to your 450?

When viewing a cache on my 450, there's a little 'gas gauge' that shows sizes:  Four blocks, a question mark, and an X for other.  Which of those popped up, if any?  To the right of those blocks, the actual size is spelled out as (size).  Is that where you saw the word "Nano"?

 

I have tried your experiment:

<Groundspeak:container>Nano</Groundspeak:container>

While it does not break the 450, it does appear both as a micro in the size 'gas gauge' and in the text that follows.

 

I should note the schema header info, and that the manual edit to the container type to 'Nano' was done after the export.

 

<?xml version="1.0" encoding="utf-8"?>
<gpx xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="1.0" creator="GSAK"
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.Groundspeak.com/cache/1/0/1 http://www.Groundspeak.com/cache/1/0/1/cache.xsd"
xmlns="http://www.topografix.com/GPX/1/0">

 

 

Edited April 12, 2020 by ecanderson

[+ecanderson]

Of interest is what GSAK does when it is imported.  It bails on the gas gauge and just shows the size.  Good, I think.