Improve geocache attribute handling

Issue #468 new
wthaemelt created an issue

Geocaches can be found on and downloaded from different servers in the Internet. The attributes of a geocache are saved in a GPX tag groundspeak:attribute. There are at least the following ways to describe one and the same attribute:

<groundspeak:attribute id="999" inc="1">text_English</groundspeak:attribute>
<groundspeak:attribute id="999" inc="1">text_language1</groundspeak:attribute>   (language1 <> English)
<groundspeak:attribute>text_language1</groundspeak:attribute>
<groundspeak:attribute>text1_language1</groundspeak:attribute>                   (text <> text1)

QMS is using a list of attribute id's. If an attribute is described in the first or second form and if the id is in this list, then QMS displays the attribute as an icon in the geocache/waypoint edit window.

If the id is not in the list (e.g. 130 - Point of interest) or if the attribute is described in one of the last 2 forms, then QMS doesn't show any attribute info in the edit window. In a few cases I've seen, text_language1 is simply the (feasible) negation of one of the attributes.

Proposed enhancement:

Display the attribute text in the edit window or at least inform the user about the fact that there are unhandled attributes, if an icon can't be found. Advantage for the user: He gets more of the information available in the GPX file about the geocache.

Would it be possible to handle this situation in the upcoming extended search, too?

Comments (2)

  1. pingurus

    We have symbols for the opencaching attributes too, I can implement them once I find time to finish the extended search.

    Most probably it would also be feasible to convert the text only to an id once the opencaching attributes are implemented. If we convert everything to an id it should be no problem in the extended search, since converting to the local language is made upon search.

  2. Log in to comment