Jump to content

Pq Gpx Cache/container/log Types (01/15/2004)


ClayJar

Recommended Posts

This list is mostly from my personal experience with GPX files. "Cache Needs Attention" is only rumored and does not yet exist (it has been mentioned only as a heads-up), but all the other types in this list have been seen "in the wild". I have also added comments to the log types, as there are quite a few that could be seen in PQ GPX files, with several of them now being deprecated and others being special in some form or another. If you have any questions or commentary, feel free to post... and if you read this, Jeremy, you can let me know if I missed anything -- or if "Cache Needs Attention" will become more than a rumor. :lol:

 

Anyway, here is the current list as of the morning of 15 Jan 2004.

  1. Log types:

    1. "Found it"
       
    2. "Didn't find it"
       
    3. "Other" (No longer available as a new log type, but still in PQ GPX files.)
       
    4. "Needs Archived"
       
    5. "Unknown" (Only older unarchive and admin actions used this.)
       
    6. "Archive (show)"
       
    7. "Archive (no show)"
       
    8. "Note" (No longer available as a new log type, but still in PQ GPX files.)
       
    9. "Webcam Photo Taken" (Equivalent to a "Found it".)
       
    10. "Write note" (Replaced "Other" and "Note".)
       
    11. "Unarchive"
       
    12. "Attended" (Seen on CITO caches; likely equivalent to a "Found it".)
       
    13. "Will Attend" (Seen on CITO caches; likely equivalent to a "Write note".)
       
    14. "Cache Needs Attention" (Rumored but not yet present.)

[*]Containers (Sizes)

  1. "Not Listed"
     
  2. "Micro"
     
  3. "Regular"
     
  4. "Large"
     
  5. "Other"
     
  6. "Virtual"
     
  7. "Not chosen" (Seen in a PQ GPX, but no idea where it came from.)

[*]Cache Types

  1. "Traditional Cache"
     
  2. "Multi-Cache"
     
  3. "Virtual Cache"
     
  4. "Letterbox Hybrid"
     
  5. "Event Cache"
     
  6. "Webcam Cache"
     
  7. "Unknown Cache"
     
  8. "Locationless (Reverse) Cache"
     
  9. "Project APE Cache"
     
  10. "Cache In Trash Out Event"

Link to comment
Older caches that were around before we had the container field defaulted to "not chosen." Now that it is a required field you don't tend to see that one anymore.

That's odd, as the event cache I mentioned above is only about a month old. It's not an old, resurrected cache either, as you can tell by its waypoint ID.

Link to comment
It appears that "Will Attend" and "Attended" might be applicable to all event cache and not just CITO events.

While it may indeed be the case that "Attended" and "Will Attend" would be a great match for plain old event caches, that really doesn't matter at all to this this thread. This thread is intended simply to document the types so that we developers can be sure we know about them all.

 

It seems logical that "Attended" and "Will Attend" could end up on plain old event caches. It also seems logical that if those two log types remain on CITO events, "Found it" will then be removed from the log options for CITO events. Still, none of that matters to the PQ GPX application developers' side of things. For us, as long as we know what *could* be thrown at us, that's fine. (Of course, it's also nice to know what the things mean and where they come from, which is why I listed that information.)

Link to comment

Hehe... well, to be completely correct, in the PQ GPX files, we're seeing two nots:

  • Not Listed (The owner decided not to list the cache container/size.)
  • Not chosen (The owner didn't choose anything from the list.)

"Not chosen" is no longer a possibility, since the "Cache Size?" answer defaults to "Not Listed", but as there are caches which were created before this was the case, "Not chosen" exists. It shouldn't show up anymore, of couse, since now there is a default. (Ed: Of course, it likely won't show up any less, either. B))

Edited by ClayJar
Link to comment

Alright! B)B)

 

My list exactly matches ClayJar's list! Something went right today! :blink:

 

Regarding the two "attended" log types, I seem to remember seeing those on regular events for a while, then it was changed back. But as CJ says, it doesn't matter. We just need to know what to expect overall.

Link to comment

Considering my poor Engrish, in the next version of the Groundspeak:cache namespace I would rather if we created GUIDs that developers could use in place of the English version of the log. That way if I change "Not Listed" to "NA" your app still hums along. The English will still be there but I can change it to German if I wanted.

Link to comment
Considering my poor Engrish, in the next version of the Groundspeak:cache namespace I would rather if we created GUIDs that developers could use in place of the English version of the log.

Enumerated IDs would be great, especially if they could be put into the DTD, so that a Groundspeak-extended GPX file could be validated.

 

GUIDs, on the other hand, would be horrible. GUIDs are incredibly difficult to use, and they are complete overkill for this purpose. I seriously doubt that there will ever be 2^128 cache types. B)

Link to comment
Considering my poor Engrish, in the next version of the Groundspeak:cache namespace I would rather if we created GUIDs that developers could use in place of the English version of the log.

Yuck! Enumerated values are fine - preferable, actually. But this recent obsession with GUIDs does the geocaching software industry no good. It adds complexity (go ahead, use them as an index in a table lookup) size (replacing a 5-6 digit UID with a 32 digit hex ID) and general ickiness.

 

Message numbers are OK. You'd get bonus points for publishing them in the DTD. The non-english speaking world could then easily i18nize them. But please don't use more GUIDs.

Link to comment
Considering my poor Engrish, in the next version of the Groundspeak:cache namespace I would rather if we created GUIDs that developers could use in place of the English version of the log. That way if I change "Not Listed" to "NA" your app still hums along. The English will still be there but I can change it to German if I wanted.

That last sentence (emphasis mine) is perhaps a valid reason for going to numeric type IDs with descriptions as opposed to the current names. Otherwise, adding even more mappings to an already extensive library strikes me as a very bad idea. Also, if we wanted to go to a binary format, where everything is random numbers with meanings, we could just go to one. The nice thing about XML is that you can write XML that isn't just a random smattering of 1s and 0s; if you were to abandon that, it would make far more sense to abandon it completely and go to a much more compact machine-readable format.

 

There is also a new development in the Watcher 0.2.42 code (not yet publically released) that could be very adversely affected by changing from nice, XML-style words to magic numbers of GCc internal significance. Watcher 0.2.42 now has plugins for Geocaching.com types, fuzzy's bmgpx file cache/container/log types, and any other typesets that people create. For example, if someone is into geodashing, they can add the geodashing plugin and merge a geodashing file with their PQ GPX files, then filter, sort, and use all the normal functionality of Watcher with the complete set of waypoints, Geocaching.com and otherwise. Going to "magic numbers" would create the need for some way of assigning such numbers, which would mean that changes at Geocaching.com could break anyone else's datasets. With the current, working, and proper method, fuzzy just needs to name his types appropriately (say, "bmgpx_recovered" for a log type).

 

This is not to say that it would be a bad idea to segment the PQ GPX types from the Geocaching.com display types. If you call it "Not Listed" in the GPX, you can rename it on Geocaching.com and have the PQ Generator use the old name. In fact, if you wanted, you could even make "Other", "Note", and "Write Note" all call themselves the same thing (not that we could stop supporting the old versions, of course). If you wanted to give nice GPX names to all the cache, container, and log types, that'd be fine with me, but there's no reason to go to magic numbers.

 

(If you want an example about how magic numbers are bad, just look at everyone trying to get rid of them.)

Link to comment

ClayJar...

 

Thanks for creating this list :huh: I wish I had it when I first started working on GPXSonar...

 

About the GUIDs vs. IDs issue: my personal preference would be to stay away from GUIDs: they're too large in the first place and require some mapping for lookups (again). Straight indexing using enums would be nicer.

 

Jeremy...

 

For multi-lingual support using enums, you could provide a "header" containing the equivalences between the enums and the strings to be displayed. This could be automated based on the geographical area selected in the PQ. That way, no matter what changes, the applications consuming the xml always do the right thing.

 

Regards,

Fabien.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...