Jump to content

Multistage waypoint type changes break third party apps


EngPhil

Recommended Posts

It appears that a recent change to waypoint types has had some very nasty effects on third party apps.

 

Previously, multistage waypoints were marked as "Question to Answer" or "Stages of a Multicache". Now they are "Virtual" and "Physical" waypoints.

 

Unfortunately these waypoint types are apparently not known to other apps that use the API or GPX files. This results in all multicache waypoints (and presumably those attached to other caches as well) not being handled correctly -- Geosphere, for example, now sees "Virtual" waypoints as standalone Virtual Caches. That's.... bad.

 

Can this change please be rolled back before it bites anybody else?

Edited by EngPhil
Link to comment

[...]

Unfortunately these waypoint types are apparently not known to other apps that use the API or GPX files. [...]

 

You're wrong. Apps that correctly use the sym tag do NOT fail.

GSAK does import GPX and Api children data with their appropriate types. :)

 

Hans

Link to comment

You're wrong.

And that kind of attitude reminds me of why I don't often post or lurk here. Thanks.

 

I posted an example of an app where it fails. Clearly GSAK handles things differently (but, I note, still not completely cleanly.)

 

I noticed c:geo is broken since the update. That app hijacks the data from gc.com though, from what I'm told. So I'm sure Groundspeak isn't losing too much sleep over it.

Link to comment

You'd better post that in the app's support forum. :blink:

Thank you, Mr Troll. I came here from there when it became apparent that a random change in the source data affecting multiple apps had occurred.

 

Do you really have the f...g nerve to call me a troll? That's ridiculous and unpolite.

 

Hans

Link to comment

I found today that when I downloaded a multi-cache to my Oregon 600, the description did not give me any details of the stages or the questions to answer. Is this part of the same problem? Do I have to revert to printing out multi-caches to be able to find them??

 

Chris

 

I downloaded a multi to my eTrex 20 and got the expected results but I'm not sure the construction matches the one you are having trouble with. Care to share the GC number of your trouble cache?

Link to comment

[...]

Unfortunately these waypoint types are apparently not known to other apps that use the API or GPX files. [...]

 

You're wrong. Apps that correctly use the sym tag do NOT fail.

GSAK does import GPX and Api children data with their appropriate types. :)

 

Hans

Nonsense, you're wrong.

How should the application to determine the significance of what is stated in <sym>? Where to find that "Virtual stage" has the same meaning as "Question to answer"?

Link to comment

[...]

Unfortunately these waypoint types are apparently not known to other apps that use the API or GPX files. [...]

 

You're wrong. Apps that correctly use the sym tag do NOT fail.

GSAK does import GPX and Api children data with their appropriate types. :)

 

Hans

Nonsense, you're wrong.

How should the application to determine the significance of what is stated in <sym>? Where to find that "Virtual stage" has the same meaning as "Question to answer"?

Have a look there: http://gsak.net/board/index.php?showtopic=27583&view=findpost&p=208256

and then please stop beeing unpolite and posting without any knowledge. Full stop

 

Hans

Link to comment

Ohh, I guess I get his point. It is just that he cannot see over the boundaries of his favourite GSAK. From what I've understood so far it looks like GSAK's treating child waypoints is as follows: it reads the content of the <sym> tag and adds it to the internal waypoint type table if needed (if this type is not already in there). This table is dynamically feeded. That will potentially result in having "Question to answer", "Virtual stage", "Stage of a multicache" and "Physical stage" in the table at the same time if all caches in the database don't get updated. Icons are not assigned to these new types or are assigned incorrectly (as has happened with "Physical stage" which is shown with parking area icon in maps). Needs an update to correct this minor glitch.

 

Another cache management applications have static (hardcoded) waypoint type table (Geoget, aDrake). These have troubles when a "Virtual stage"/"Physical stage" arrive in <sym> tag after yesterday's update and don't know what to do with them. They need update. No mixtures of new and old waypoint types and no wrong image/icon assignments in these apps.

 

It is no problem to count with changes but yesterday's change hadn't been announced to application developers.

Edited by Pontiac_CZ
Link to comment

It would appear his point is that they changed the XML <sym> content and blindsided all of the 3rd party folks. Not sure he needs to make any better point than that.

 

Let's talk about that <sym> element. A GPX file is just an xml file and like every other xml file used for data exchange, the structure and nature of the file is defined in either a "dtd" file (the old way) or schema file. A GPX xml file uses a schema, which actually consist of a base schema and Groundspeak extensions (the X in XML stands for eXtensible). The purpose of a XML schema is to define a specific set of elements which can be found in the xml file, the order in which elements may appear, whether or not some elements are required or optional, and importantly for this discussion, *optionally* define constraints on the content within an element.

 

For example, the schema may define that an element only contains integers, or a string. It can also define bounds on an element. For example, an schema might dictate that a <color> element only contains "red", "white", or "blue". It has constrained the <color> element such that it only contain a specific set of values. If the Groundspeak schema extension defines the <sym> element such that it will always contain a string, but has not put a constraint on it such that it only contains "Answer to Question" or "Stage of a Multicache", and they put "Virtual" or "Physical" instead, they have not blindsided 3rd party developers because the schema allows for *any* string in that element. A 3rd party developer which makes the assumption that the <sym> element only contains "Answer to Question" or "Stage of a Multicache" is making an erroneous assumption.

 

Granted, it would have been nice if Groundspeak was able inform all 3rd developers of their intention on using different string for the sym element but the onus is really on the 3rd party developer to understand the schema and not make assumptions that could potentially break their application.

Link to comment

And at any point a developer alters the schema, 3rd party developers should be notified. Ideally, the schema should be the guide by which to hard code (to whatever degree) functionality and data checks. If the schema itself changes, it can break things. If the data changes, and the schema was accurate and software were programmed correctly, then there should be zero issue.

 

If the <sym> tag allows for a unique identifier for the waypoint type, with the text in addition to that, then altering the text and retaining the unique id shouldn't break 3rd party apps. But as it is, if the apps use the text as the unique identifier, then there is no way for the app to decide if the change implies a new waypoint type, or an alteration to the existing type. They'd need to write a little script that, in this case, would update all its old waypoints to the new text. (until they properly code the schema into the app).

 

Nonetheless, IMO ultimately it's Groundspeak's choice/prerogative to inform developers of significant change, if they think there's a possibility it could cause problems (even if it shouldn't). Except maybe c:geo, they're on their own. :laughing:

Edited by thebruce0
Link to comment

If the <sym> tag allows for a unique identifier for the waypoint type, with the text in addition to that, then altering the text and retaining the unique id shouldn't break 3rd party apps. But as it is, if the apps use the text as the unique identifier, then there is no way for the app to decide if the change implies a new waypoint type, or an alteration to the existing type. They'd need to write a little script that, in this case, would update all its old waypoints to the new text. (until they properly code the schema into the app).

 

Great explanation. That's essentially what we ran into on bcaching.com. Bcaching maps the sym text to an internal unique ID based on external configuration and does not automatically add new IDs if they show up (oops). Although GPX processing broke after the change, it was fortunately a simple matter to add the new mapping to the configuration. Bcaching doesn't get much traffic so few people were impacted but a heads up would still have been nice.

 

Bad design you say? Perhaps. But design is a balancing act in which future proofing is just one of many factors.

Link to comment

...If the Groundspeak schema extension defines the <sym> element such that it will always contain a string, but has not put a constraint on it such that it only contains "Answer to Question" or "Stage of a Multicache", and they put "Virtual" or "Physical" instead, they have not blindsided 3rd party developers because the schema allows for *any* string in that element. A 3rd party developer which makes the assumption that the <sym> element only contains "Answer to Question" or "Stage of a Multicache" is making an erroneous assumption.

All this means is that an application shouldn't break with new values, however the application will not be able to take full advantage of the new values because the meanings are unknown.

 

It's difficult to make intelligent choices about something if there is no information about what it is.

Link to comment

It would appear his point is that they changed the XML <sym> content and blindsided all of the 3rd party folks. Not sure he needs to make any better point than that.

 

Let's talk about that <sym> element.

No need. I understand the need for a robust handling of XML content to avoid actual breakdown of the code in the event of unexpected values. However, this most recent change seems to have caught the 'partner' developers by surprise, and for good reason, they do not know what to best do with the new content. When gc.com makes such changes, I do not understand why all 3rd party partner organizations with access to the API would not be notified in advance of a change like that.
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...