When you download a geocache file from our site (for use with your handheld GPS device or private geocaching database) you get bits of important information about an individual geocache or group of geocaches. Over the years, the community has requested that more pieces of helpful information be added to that file.
Geocaching community: We want to make sure that we are adding the right pieces of information to the files so that the community ends up being happy. This is incredibly important, since you are the ones that will be using it everyday.
Partners: We want to make sure that we have important conversations with our partners who make the hardware/software that use these files. It is important that everyone is on the same page so that GPS handheld devices and the file work well together.
This is the very first step in a process that will take a few months from start to finish. We want to hear from the community and find out which information about geocaches is important to you. After we hear your thoughts, we will begin the conversation with our partners to find out what they think. Together, we will come up with something great!
Below you will find all the information that the current file (GPX 1.0.1) offers, as well as some potential additions that have often been requested by the community.
Let us know what information isn’t necessary in this file. What is taking up file space that shouldn’t be? What else do you not find useful?
This thread will remain open for 2 weeks and close on September 10th. Please read the User Insights Forum Guidelines before posting, since these threads are moderated a bit differently than other forums.
Thanks for taking part in this conversation!
Additional waypoints would make sense, I could never understand why a pocket query consisted of one file for the caches and another file for the associated waypoints.
Corrected coordinates would be useful, but only if those with corrected coordinates were identified as such. On a related note it would be handy to be able to exclude puzzle caches that weren't marked as solved from pocket queries.
Logs by friends should be able to fit within the current schema.
I'd be inclined to put things like information about the placer, bookmark lists and cache finds for previous finders in a separate file and make it optional whether to download it. If you've got a cache that has been found hundreds or thousands of times and list the other caches found by finders of the cache you could be generating a monstrous great file.
Personally I don't care about favourite points or PMO status so don't really have anything to say about those. As long as their addition didn't break anything I'm neutral on that.
Personal cache notes would be handy. I wrote my own piece of software to manage GPX files and deal with things like unsolved puzzles and caches I had no interest in ever attempting (typically urban nanos and anything a long way up a tree or down a hole). I just added my cache notes to the cache description when exporting GPX files for use in the field. A separate field might be useful if it didn't break anything downstream, but if a note were clearly marked it could potentially be put into the cache description if new fields would cause issues.
We were told a couple of years ago that an updated GPX schema was no longer planned, so I'm glad to hear it's at least being considered now.
I would assume a new schema would be optional like 1.0.1 is now and would be called something like 1.0.2? It definitely needs to be optional, though, and the older versions must remain available for backward compatibility. Some older GPSrs would choke pretty severely if they were force-fed a new version.
Information about placer - It depends on what this information is. If it means things like find/hide count, email address (if marked as public), etc., then I'd support including it.
Cache finds for previous finders - It isn't clear what this is. Does this mean the inclusion of any of my logs? If so, I support it.
I also noticed you only refer to this as a "downloadable geocache file", without calling it GPX. I infer from this that other formats are also being considered, with the most obvious possibility being Garmin's GGZ file format. As long as GPX files remain available, I'm sure GGZ would be a welcome addition for those with newer Garmin GPSrs.
Cache finds for previous finders (assuming this means the number of finds, similar to what is shown on the cache page below the log owner's avatar next to their log).
I'd also ask that you create and maintain consistency between the data delivered in the new format downloadable files and the data delivered by the SearchForGeocaches and GetMoreGeocaches API calls. Inconsistencies in the data delivered by the two methods create a great deal of confusion and leads to increased demand on the Groundspeak servers (e.g. caches are obtained via Pocket Query or cache page download, then have to be refreshed using the API just to update Favorite Points).
Another useful bit of information would be the total number of logged visits, as shown on the cache page. Like consistency in data between methods, this would decrease the demand on the Groundspeak servers (e.g. knowing the total number of logs would allow a user to get a "Published" log for challenges without having to download all of the logs on the cache).
I think including the published date, when available would be very helpful. Also, I'm wondering why you state date/time placed when only the date has meaning. Time is worthless and should be discarded. Likewise with the time with anything, such as logs etc. Time is meaningless and has only caused grief. Just stick to date and forget about time and life would be much simpler.
As long as this update doesn't change the way my Oregon 450 handles the data, I guess it would be acceptable. If this proposed change dorks up the way GPSr handle the GPX downloads, PLEASE DON'T, unless you also make the current data file type available as an option.
PLEASE DON'T DO THIS 'UPGRADE' LIKE YOU DID WITH THE NON-TEXT EMAILS. MAKE IT AN OPTIONAL CHOICE FOR THE USER.
Here are the bits of information that stood out to me when I read through the lists. The bits I don't comment on probably fall into the "of course you'll include that" category, and I have no further comments on them.
Size - Would that include adding a separate nano size? If you're still thinking of doing it, then now's the time.
Favorite points - I'd find it useful to be able to filter PQs based on Favorites or based on Favorite Percentages, but I really don't care whether these are in the downloadable file. I'm sure those who use GSAK and other third-party processors would find it useful though.
Premium Member only status - Again, I really don't care whether these are in the downloadable file. To my mind, one of the perks of being a premium member is that I can ignore the PMO status of caches.
Personal cache note - I would like to see these in the downloadable file. I would ALSO like to be able to filter PQs based on these. And I'd like to filter both ways, to list puzzle caches that I have solved as well as puzzle caches that I have NOT solved.
Friends’ logs - Okay, part of me things it's cool to do something useful with the Friends feature at last. But the rest of me doesn't care, unless my friends' logs are in the logs that I'd be downloading anyway.
Additional waypoints - The current way works, but I agree that it would be nice to have additional waypoints stored with the cache data, instead of in a separate file. For one thing, it would make it easier to write a Perl/Python script to process cache data that includes additional waypoints.
Information about placer - What kind of information? It might be useful to know that someone has a reputation for intentionally soft coordinates, or for listing caches with the wrong size. But I don't care about things like date joined, or number of caches found/owned, or number of trackables moved/owned/discovered, or things like that.
And finally, it is REALLY encouraging that you're asking this question!
About waypoints, I don't see much sense on having them on a separate file.
There are really only two things that I would like to comment on.
As NiraD said, this would be the perfect opportunity to finally include a "nano" size. As stated in the second comment in this thread, the only reason it never was implemented was because a change would have to be made to the GPX schema.
The only other thing that isn't already included that I would like to see is favorite points. Even if it's not a percentage, just the straight number would be very helpful.
Thanks for including us in the discussion!
First a couple general comments. First I think that the API, PQs and the GPX File button on the cache page should all deliver the same data. If there are differences people get confused. This means that in the future if you add a data item to one, the others should also get that data item added.
Additionally I think additional data items in the PQ needs to be user selectable. A few years ago attributes where added to the PQ file and users ended up with bricked GPS units. We now have 1.0 and 1.0.1. Might I suggest a 1.0.2 for the new changes plus the attributes in 1.0.1. 3rd party software can change to adopt to the changes but to expect equipment manufactures to roll firmware on obsolete and out of support life on their hardware is probably unreasonable. And I'm sure a number of folks are still happily using those units.
I'm not sure about Friends logs. I personally see little use for that but if it is there no big deal.
I don't see the value of bookmark lists in the download. I really can't think of a good way to use that item. Far as I'm concerned if it is not there no big loss.
Information about placer is something I would consider useless. Rarely do I go looking up that information and I would rather not fill up my database with useless information.
Cache finds for previous finders. I don't understand this one. Is it the number of finds the previous finders have? If so that, in my opinion, is useless database padding. Although I'm sure the Grand High Poobah would find it useful. If it is something else please elaborate.
Image links is pretty iffy for me. I don't see a lot of need for them and probably consider them space wasting data.
The others are fine, and if fact should be there.
What is missing is the number of logs on a cache and probably more important is the published date if available.
The additional information I would find most useful--the only additional information that I remember ever wishing was included--is the Personal Cache Note.
I think the inclusion of bookmark lists would be useful. It could help to implement a if you like this you might like these kind of feature through a back door. I have always wished that back when Jeremy started the site, he had had the foresight to implement tagging. My vision is that bookmarks could do this in part. I download a cache at a rest area and get a link to a bookmark of other rest area caches or I discover that a cache I really liked is on a list of another players favorites.
...I think that the API, PQs and the GPX File button on the cache page should all deliver the same data. If there are differences people get confused. This means that in the future if you add a data item to one, the others should also get that data item added.
I think this is actually one of the most important factors in updating the downloadable file content. The file content, API, and Pocket Query form are all very closely related and need to be updated in parallel. Making a change to one without updating the others leads to problems like we have now with the corrected coordinate feature (you can change the coordinates, but this isn't respected by other parts of the website or some of the content-download features). Updating the file content without also updating the Pocket Query page (or introducing a new search/filter feature) would be a major failure. These need to be worked on at the same time to ensure consistency. Please don't update the file content and then leave the same antiquated Pocket Query page in place for years.
It would be really helpful it these were provided with the GPX file !
I wholeheartedly endorse the concept of maintaining the current system and making any changes optional. I have taken my well worn Garmin 76Cx over 275,000 miles (including my pre-geocaching travels) and it does fine for my needs.
I do not need ANY of the listed changes and I would be quite miffed if a new format were released as the sole format and my GPSr was no longer compatible.
Beyond the wishes already posted I'd like to add "County" to the wish list.
It would be great if GS updated its country/state polygon files. It happens quite often that caches hidden at the edge of a country or state gets "moved" into the wrong area.
Example: GC20RGR ("Kiekkaaste - WS 4") is located in the Netherlands (Groningen province, as clearly visible on gc.com map, Google Earth, Bing and others), but according to its cache data it lies in Niedersachsen, Germany.
As far as I understand it, the cache owner is solely responsible for setting the Country and State fields in the cache listing. They are not figured out from whether a cache lies within some polygon or not.
We use a Magellan explorist GC so the current file format works fine for us, but the addition of "corrected coordinates with flag" would be great.
Any, and all ways of getting cache information,from Groundspeak should provide the same information from all sources.
As we're driving and looking at caches on the gps, I'm always wishing I knew how many favorites were given. Also, if I have multiple PQs loaded (Fizzy, Jasmer, Date Hidden), it would be nice to know which cache went with which challenge. I've tried to change the gpx file by changing the cache title, but haven't been able to get it to show on the gps, so being able to see which of my bookmark lists it belonged to, if any, would be helpful. As other posters have said, as long as it doesn't mess up the current compatibility, these changes would be most welcome.
You have a cache in your Jasmer bookmark list and want it identified. I have the same cache in my road trip bookmark. How should GC identify the cache in these two different cases? I see nothing but problems here, especially if I don't want any special identification.
Naturally there has to be a new version, and I think it has to be user selectable like the 1.0.1 version was.
But more importantly is to pay a lot of attention to making sure future versions are backwards compatible so this stops being an issue in the future. I don't know anything about the actual cause of problems with new versions of PQ data, but whether the problem is data design, unclear rules for implementers, or just dumb implementations, everything possible should be done to make sure third parties know exactly how to interpret the data to avoid problems when the data is expanded to add new features.
I see the idea behind Friends logs, but I request caution. In particular, it's possible that many of my friends found the cache years ago, so I don't want their ancient history to keep out recent logs with fresh information.
The number of finds of each previous logger would be very useful. I'm not sure how many times I've been discouraged by a series of DNFs that I later discovered were all newbies that didn't know enough to lift a skirt. And, on the other hand, I don't want to be dependent on me recognizing someone's name to know that it was an experience user that recently failed to find this cache.
I think the idea is to include all the book mark lists the cache is in, just as it shows on the cache's web page, although I'm hoping the idea is to limit it to my own bookmarks. The bookmark lists of other people are interesting on the web, but I think they'd rarely be useful in the field.
Yes, just your own personal bookmarks. I wouldn't care about anyone else's when I'm out and about.
XML (the underlying format of the GPX file) can represent dates on their own as well as date times though I would argue the time zone is still essential for a date on its own. However, the content of the GPX file does not need to be limited to what the software reading it will want to display. My day job involves working with XML files and I would go for consistency rather than second guessing how the file will be used. Regarding cache placed dates, if these are when the reviewer signed it off then I agree the time is not important at all. Log times are perhaps more valuable, as some caches are daytime only or are in places affected by the rush hour.
Related to this, I would ask GS to ensure that the time zones are correct for all the dates and datetimes in the file.
I have no problem with any of these. I cannot guarantee that I will use all of them (I am another user with personal software). With regard to corrected coordinates it might be useful to have the date and time the correction was made. Also is it possible to have more than one coord correction per cache, in that case all should be output.
Corrected coordinates would probably benefit quite a lot of people. Unlike one post above related to GSAK - I don't have a multiple-step issue since download, correct and keep all of my Puzzle solutions (and often, the next location of a complicated multi) in a separate GSAK database that gets loaded to the unit every week. But if a user hasn't adopted a 3rd party solution, this would be a BIG improvement.
I can also imagine that personal cache notes would be of value to many, though this could be managed now and without changing the schema by simply pre-pending that information to the logs as a separate 'dummy' log entry.
Of the new suggested information, the personal cache note is the one I would love to have.
The others seem OK, but I doubt I'd find them useful. As I already mentioned, logs of my friends is an interesting idea, but I stress that they are less important than more recent logs and should not displace any more recent logs.
As I mentioned in another response, I assume this is the number of cache finds for the owner of any of the listed logs. I would find that useful, particularly if it includes DNFers as well as Finders.
I've never understood why the waypoints are in a separate GPX file in the ZIP file, and I've also never understood why there's nothing in the XML structure to link the waypoints to their corresponding geocache. The only connection between them is that the waypoints are mentioned in a section of text appended to the long_description field of the cache.
I really don't need to know about the Favorite points when I'm already searching for the cache. And how useful could it be, to know, if the cache is Premium or not? It's already on my handheld, so this explains itself. Image links,bookmark list, etc - well yeah, perhaps useful for Smartphone-Cachers. But I think, they don't have to download a file...?
Perhaps it would be an idea to give every cacher the possibility in the personal settings, which information should be offered in the downloadable file?
Besides that: Really great, that Groundspeak comes back to hear on those who play the game ;-) Thanks a lot for this!
The ideas presented so far are in two categories. Some answer the exact question of what needs to be added to downloadable geocache file format (which I'll refer to as the DGFF). Some suggest additions to the content which could be handled in the current DGFF. I understand the need for long-term planning regarding the DGFF and thus the need to consider this as a separate issue in development. However, I hope the development team will consider the other ideas presented, partly because they are clearly of interest to geocachers, and partly just in case some might be better implemented with a format change even though they could be implemented within the current DGFF.
I generally support the ideas mentioned, both DGFF additions and content additions. I'll make a few comments on the proposed additions and then some additional ideas.
Friends’ logs: I'm not sure what this means. If it means "include my friends' logs in the download", this does not require a DGFF change. In any case, the Friends feature is still so shallow that it's little used. I'd say design the completed Friends feature before deciding how it affects downloads.
Image links: I haven't looked, but I was under the impression that at least some were already provided. What exactly would this be? I do want to be able to grab the image links from logs.
Bookmark List: What is this? As others have pointed out, a cache can be on many bookmark lists, and it's not clear which would be useful to report.
Information about placer: Again, what is this? The "placed by" text field and the current owner ID are already provided. I would like to see information about the original hider, as I discuss below.
I'd like to present three ideas which are not strictly a matter of the DGFF but are closely related. One of these clearly does not require a DGFF change. One certainly requires a change. For the third, a DGFF change might be useful but not required.
Help find gaps: Provide an option to include my found log(s) and the last previous found or published log(s). This has a narrow purpose: to help those pursuing "lonely cache" challenges which require logging finds with certain gaps from the previous finds. Presently the only way to get all the information needed to determine progress and eligibility is to download all logs from every found cache. This process is time-consuming for the user, expensive for gc.com, and wasteful on both counts. The suggestion would provide all the needed information with a download of, usually, just two logs.
This is only a new content option and should not require any DGFF or database changes.
Hider vs owner: Recognize the distinction between hider and owner. As more older caches are adopted by new owners, this old problem gets worse. We often need to know both the (original) hider and the (current) owner.
This would probably require database changes, DGFF changes, and UI changes.
Better selection: Add modification timestamp items to each cache and log, and use these to determine what items to include in future PQs and API downloads. The idea is that a PQ or API download request could then say "send all cache and log records which were added or modified since <<date/time>>". This would improve the accuracy of downloads while reducing overhead, with minimal history of prior downloads.
This would require database changes if cache and log entries do not already have modification timestamps, but no other database changes. It probably would not require a DGFF change, depending on how it is implemented. The timestamp could be added to the DGFF, but this is probably not necessary; instead, the user or user's software could save a single timestamp which is prior to the request, and use this as the "since" parameter. The PQ system should be changed to add an option "all new and changed since last run of this PQ".
This proposal does not address the long-standing issue of needing notice of caches which disappear from PQs due to being archived. I'll leave that for the future.
Since we are talking about downloadable Pocket Queries, I would like to see the "My Finds" query include the Lab Caches with a unique cacheid (that does not interfere with other caches) and an unique GC number or LB number (Lab cache). Having the descriptions available for the lab caches in the PQ would be nice also. This will allow people to download ALL of their finds, not just typical caches.
I also agree that have all the different ways of getting data should supply the same data.
I like the proposed changes, but I would like to see the following added to be able to query against.
+1 for including Fav points.
While traveling, I look for "special" caches, and try to weed out the lamppost micros. One indicator to go by is the Favorite points.
Does anybody really want to tell me, that you are NOT planning your cache tours on the computer but absolutely spontaneous with the GPS?
And that you than decide by Favs?
We are NOT talking about the PocketQueries, or do we?
We're talking about the single GPX downloadable for the GPS?
Even if any of these additions don't cause problems with existing GPS receivers there is still the issue of whether or not companies like Garmin will provide firmware upgrades to support the new elements. If a new version of the GPX Groundspeak extensions is created which includes corrected coordinates and personal notes it's of little use unless a GPS receiver is capable of doing something useful with that information. I suppose that the official Geocaching apps might be the first to use it but an update to the GPX format is unlikely going to help users of older GPS receivers like the Garmin 76cx or 60 series.
And to clarify, the inclusion of the number a favorite point a specific cache has in the GPX file is not necessary for filtering for caches with a minimum number of favorite points. If you want to week out caches which have fewer than, say, 10 favorite points, being able to add favorite points as a criteria when creating the PQ will do that. The GPX file would only contain caches which had 10 or more favorites and it doesn't really matter exactly how many a cache has as long as it's at least 10.
Thank you for providing this opportunity to give some input on the topic before you get into the implementation phase and rollout.
I'm personally missing the "corrected coordinates flag" + the "corrected coordinates" themselfes and in parallel the "original coordinates". In the actual format I get the corrected coordinates but without a flag as indicator that they are changed and without the original coordinates. So for me these three informations are needed in parallel.
I'm very interested to get the personal cache notes in the new GPX file.
All the rest is not "mandatory" for me BUT it does not harm eather and might become interesting later on (for me).
By the way: The GPX format is a XML format, isn't it. So programs should be able to extract what they want to process or what they need and ignore the rest. That's for me the advantage of XML formats: They are flexible and the programs can use what they need (or want). So it should not harm programs if they get more information as they "expect" in the XML file.
If it is fully configurable what you get in your GPX file it would be great but it is also a lot of coding to be done.
I'm happy to get the date + time as "local time" as it is today.
(2) Daylight saving change days are not the same in the US and Europe and elsewhere in the world. Between the day it changes in US and the day it changes in Europe there is a "time problem". The "automatic calculated" times are wrong (eg. for field notes!) (also a little bit off topic but related to (1)).
(3) It would be nice to be able to "correct" coordinates of WherIgos as well (ok, this is totally off topic, sorry).
Again thank you for listining to your users concerning this important change. I'm really exited to see the new format available soon - maybe on Christmas?
I am a beginner to Geocaching and am hoping that this can be a weekly activity to enjoy with my wife. I am presently struggling with how to use the website, the i-phone app and i-pad apps. I am uncertain whether I should invest money in a handheld device or if my i-phone and i-pad will suffice.
Regarding downloading to devices, I would love to learn how to master these types of functions, so that I am not as clumsy out in the field during the search for caches.
My suggestion is for the development of a simple tutorial with "just in time learning" presented in video or perhaps you Tube format. A step by step video would be helpful to cachers like me who learn by watching and then by doing.
Edited September 1, 2014 by T F Machine !
The original post only referred to "downloadable geocache file format", so I abbreviated it as DGFF. However, it's clear that what is being discussed is the GPX format. A lot of advance planning is required to change the GPX format, which is part of the reason this is being made a Big Deal with this discussion.
GPX is the format used for single-cache downloads, pocket queries, and the API. Therefore the changes will affect all these.
GPX is also the way GSAK and other third-party geocaching applications get their data. GSAK will certainly be updated to handle any potentially useful data added to the GPX format. Many of those older GPS units are being loaded via GSAK, so they will benefit.
The API does not use GPX.
I'm talking about Routes Created and saved to Pocket Query, yes. When we're driving from place to place, we don't stop and get every cache on the route. But it would be nice to be able to see on the GPS, here's one coming up, it's got quite a few favorites, let's go check it out. So yes. Honestly.
The Refresh Cache Data function in GSAK claims to generate a GPX file and then load it. Are you saying that the "generating GPX file" message means that GSAK generates the GPX file from other data, and then loads it?
Of course there are other functions of the API which do not use GPX.
Thanks for adding to the discussion! I'll try to clarify my understanding around a few of these feature requests, although they originally came from the community. If there are folks out there that want to clarify how they see these features working we would welcome that too!
This means that your friends' logs for that cache would be included in the file. It would be up to the 3rd party applications to find a way to display that data in a helpful manner, but we have heard from community members that this could be helpful in tough hunts - an easy way to see who has found the cache that you know. A built in phone-a-friend. In the future we would like to improve the friends features and that may make a difference in the usability of this potential feature.
Image links aren't currently included in the file (unless they are added manually by the owner as part of the HTML description). We would like the file to be able to handle image links from logs and the description. GSAK users most likely get them because they update with the API and that pulls them in. Having them included in the file would allow partners that use this file to pull in these pics.
This would tell you which of your bookmark lists the cache is on.
This information would include number of hides and finds by the cache placer. Unfortunately information about the original hider would be a database change. We would like to design the new file format so future improvements to the database could be included, but currently that would be a feature request outside the scope of this discussion.
There was one more question that I have seen pop up from time to time here regarding the "cache finds for previous finders" idea. As some folks have correctly guessed, this is referring to their find count.
Hopefully this helps bring some clarity around these requested additions to the file. I'll keep checking back to see if any more questions pop up. Thanks for all the feedback, gang. We appreciate you sharing your thoughts and experience with us.
In reviewing this thread, I think one thing was over looked. Currently when download cache data either from the cache page or via PQ you always get your log regardless how many logs might be in front of your log. That is is if your log is the 25th log on the cache page you always get your log regardless. This is not the case with the API. You only get your log if you ask for a large enough number of logs to be included. Syncing up the API to always return your log would be appreciated.
Cache finds for previous finders (number of caches in their logs) It will gives us an idea if the cacher experience.
The rest is not necessary for me.
NOTE : Additional waypoints ( I don’t load the waypoints file in my GPS) I hope you will keep that file separate like it is presently. It’s crowding too much my small GPS screen.
NOT ON YOUR LIST BUT NICE TO HAVE.
SIZE : Add nano please.
ATTRIBUTES: This one is very important for me.
You will probably talk with GARMIN concerning the changes that you want to do.
I own an Oregon 450, but I can’t have the attributes in my GPS unless I use GSAK even if I download the GPX 1.0.1 file. Can you try to convince them to modify the firmware of all their GPS to make it possible to see the attributes without GSAK, like Magelan GPS do. At least if they can add the winter available attribute that will be a beginning. They can add a new button on the geocache page with the name of SHOW THE ATTRIBUTES or it can show at the beginning of the description.
Presently on my OREGON 450 I have 4 choices to log a cache. Presently, when I push the UNATTEMPTED button, it’s like pushing a cancel button, nothing happen, no trace. That would be nice, when I log a “unattempted”, to have an icon on the GPS screen and also on geocaching.com site. That way when loading our field notes, we will have a trace that we have visited the cache. Adding this option, it will show in the right corner of the cache page where there is a big yellow smiley or the blue frown. I let you choose the smiley as long as the color is different and it is not a “?”. Also, it would be possible to filter the caches with the tab on the left side of the screen and (or) while doing a pocket querry by adding a new box in the category WHO (AND). The goal is not to log a “Didn’t find” just to a have a trace and then scare (or discourage) the others geocachers who would like to visit the cache. When I just put a note, it doesn’t show in the top right corner of the page.