Jump to content

Downloadable Geocache File Format


Jayme H

Recommended Posts

Hey there!

 

The Product Development Team is considering options for updating the downloadable geocache file format and we would like your help. For those of you that may not know what that is, we’ll explain so you can add your feedback too:

 

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.

 

Updating downloadable file formats takes some time and a lot of conversation because there are lots of moving parts. Here are some of the players:

  • 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.

  • Check out the list and let us know if there is anything missing.
  • Add comments by any item that you want to highlight letting us know why it is important/not important to you.
  • 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?

Information offered in current file:

 

Cache name

Cache type

Owner ID

GC code (cache ID)

Placed by

Hint

Size

Short description

Long description

Difficulty/Terrain

Attributes

Trackable ID

Trackable reference

Trackable name

Original coordinates

Cacher logs

Your logs

Log date

Log time

Log type

Log content

Logger’s user ID

Country/State

Date/time placed

Time stamp for file generation

Status (enabled/disabled/archived)

URL/URL name

Symbol (geocache, geocache found, geocache DNF)

 

Community requested additions to file:

 

Favorite points

Premium Member only status

Corrected coordinates (w/flag)

Friends’ logs

Personal cache note

Additional waypoints

Image links

Bookmark List

Information about placer

Cache finds for previous finders

 

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! :)

Link to comment

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.

 

BTW I'm writing based on my experiences when I was a premium member. I've let my PM lapse now so obviously as a basic member none of the above makes any difference to me, I just figured I'd throw some thoughts in the ring for what they are worth :)

Link to comment

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.

 

As far as removal, I don't think there's any unnecessary information in Groundspeak extensions 1.0.1. I feel most of the potential additions are "must haves", with a few possible exceptions:

Bookmark List - I'm not sure how useful this would be for an offline file format

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.

Link to comment

Personnaly, since I'm a very active mystery cache solver... the Personal cache notes and the corrected coordinates would be a great addition. I'm able to get them through GSAK, but it needs to be done in 2 steps... Would be a great addition if they would come up directly in our PQ. It would eliminate the need to refresh my databases only to get those 2 informations. I also think this would decrease significantly the workload of GC.com servers

 

Thank you.

Edited by Jeehell
Link to comment

Great to hear that this is under consideration. :) Based on my experience in the GSAK forums, the following items not available in current GPX downloadable files (cache page or Pocket Queries) are missed/requested/discussed the most by GSAK users:

 

Corrected coordinates (w/flag)

Favorite points

Personal cache note

Image links

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).

 

Thanks for your consideration.

Link to comment

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.

Link to comment

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.

Link to comment

Hi Jayme,

 

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.

 

Corrected coordinates (w/flag)

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!

Link to comment
Community requested additions to file:

 

Corrected coordinates (w/flag)

...

Personal cache note

...

Additional waypoints

 

 

Hello!

Thank you for the opportunity.

I quoted what I would like to see implemented just because I like Mysteries. After solving them I usually correct their coordinates and take notes directly on the page. If I could receive that information inside my PQs that would be great! Coincidentally I asked this week on GSAK forum about this "non-bug". Because doing a cache refresh through that program works fine (Via API)

 

About waypoints, I don't see much sense on having them on a separate file.

 

Regards

Edited by Bingre & NC
Link to comment

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!laugh.gif

Link to comment

Hi Jayme,

 

Thanks for the opportunity to comment.

 

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.

 

Now some specifics.

 

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.

Link to comment

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.

Link to comment

...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.

Link to comment

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.

 

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.

Edited by Michaelcycle
Link to comment

Beyond the wishes already posted I'd like to add "County" to the wish list.

 

In this context please let me add an IMPROVEMENT suggestion for one information detail already present:

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.

Edited by Geomoin
Link to comment

Beyond the wishes already posted I'd like to add "County" to the wish list.

 

In this context please let me add an IMPROVEMENT suggestion for one information detail already present:

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.

Link to comment

...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.

 

Agreed!

Any, and all ways of getting cache information,from Groundspeak should provide the same information from all sources.

Link to comment

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.

Link to comment

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.

Link to comment

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.

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'm not sure about Friends logs. I personally see little use for that but if it is there no big deal.

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.

 

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.

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.

Link to comment

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.

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.

Link to comment

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.

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.

Link to comment

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.

 

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.

Link to comment

Community requested additions to file:

 

Favorite points

Premium Member only status

Corrected coordinates (w/flag)

Friends’ logs

Personal cache note

Additional waypoints

Image links

Bookmark List

Information about placer

Cache finds for previous finders

 

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.

Link to comment

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.

Link to comment

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.

 

Cache finds for previous finders

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.

Link to comment

Ok, to be honest, the most important informations are already included to the "downloadable file formats"! But indeed, you should add at least the "corrected coordinates (w/flag)" and the "personal cache notes" and of course the "Additional Waypoints". Everything else is not useful or necessary, when you're out in the fields:

 

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...?

 

But please: Just ADD the new information, but do NOT replace the currently offered informations. And please note: There will always be small group, who wants another information in the file. Just keep in mind, which information is really useful, when you're out searching a cache...

 

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!

Link to comment

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.

 

Comments on listed proposals

 

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.

 

Additional waypoints: Most of the responses have centered on two files vs one. The problem I have with the current format is the inclusion of Additional Waypoints in the Long Description. This often causes GSAK to think the description has changed and adds a lot of noise to the download report. (I'm not sure exactly why, but it doesn't matter -- they should have their own element.)

 

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.

 

Other ideas

 

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.

 

Edward

Link to comment

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.

 

Thanks for listening.

Link to comment

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?

Honestly?

 

We are NOT talking about the PocketQueries, or do we?

We're talking about the single GPX downloadable for the GPS?

Link to comment

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.

 

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.

 

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.

 

 

Link to comment

+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.

 

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.

Link to comment

 

[...]

 

Community requested additions to file:

 

Favorite points

Premium Member only status

Corrected coordinates (w/flag)

Friends’ logs

Personal cache note

Additional waypoints

Image links

Bookmark List

Information about placer

Cache finds for previous finders

 

[...]

 

 

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.

 

The most important thing is, that data is consistent regardless of the way you get it: PQ, GPX download of single cache, API, ...

 

In some feedbacks I saw comments which are a little bit "off topic" but with close link to this thread. So maybe I can add some ideas for them as well:

 

(1) Concerning times and time zones it would be helpful to get the "correct" times based on the time zone. So either it is calculated by GS and delivered as "local time base on timezone set in profile" or it is delivered as "time + timezone". But in the later case it would be possible that the date has to be "corrected" as well in order to fit. Implementation depends how it is stored in the GS database ;)

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?

Link to comment

Hey there!

 

The Product Development Team is considering options for updating the downloadable geocache file format and we would like your help. For those of you that may not know what that is, we’ll explain so you can add your feedback too:

 

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.

 

Updating downloadable file formats takes some time and a lot of conversation because there are lots of moving parts. Here are some of the players:

  • 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.

  • Check out the list and let us know if there is anything missing.
  • Add comments by any item that you want to highlight letting us know why it is important/not important to you.
  • 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?

Information offered in current file:

 

Cache name

Cache type

Owner ID

GC code (cache ID)

Placed by

Hint

Size

Short description

Long description

Difficulty/Terrain

Attributes

Trackable ID

Trackable reference

Trackable name

Original coordinates

Cacher logs

Your logs

Log date

Log time

Log type

Log content

Logger’s user ID

Country/State

Date/time placed

Time stamp for file generation

Status (enabled/disabled/archived)

URL/URL name

Symbol (geocache, geocache found, geocache DNF)

 

Community requested additions to file:

 

Favorite points

Premium Member only status

Corrected coordinates (w/flag)

Friends’ logs

Personal cache note

Additional waypoints

Image links

Bookmark List

Information about placer

Cache finds for previous finders

 

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! :)

 

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.

 

Thanks for allowing me to share my thoughts. T F Machine

Edited by T F Machine !
Link to comment
We are NOT talking about the PocketQueries, or do we?

We're talking about the single GPX downloadable for the GPS?

 

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.

 

Edward

Link to comment
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.

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.

 

Edward

Link to comment

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?

Honestly?

 

We are NOT talking about the PocketQueries, or do we?

We're talking about the single GPX downloadable for the GPS?

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.

Link to comment
The API does not use GPX.

 

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.

 

Edward

Link to comment

Hey everyone,

 

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! :)

 

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.

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: 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.

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.

 

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.

This would tell you which of your bookmark lists the cache is on.

 

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.

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.

Link to comment

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.

Link to comment

This page already contains a lot of useful and nice ideas, but I think an important point here hasn't been discussed:

 

The format of the file itself. I think I can remember some other thread here in this forum ages ago about this issue. I guess it might be a good idea to use integral IDs for stuff like cache size and cache type and define their meaning somewhere else in a shema file or whatever. This might make it harder for humans to read/interpret the file, but will enable software to handle new types/sizes more flexible. So for example the recent change which renamed "Unknown" to "Mystery" caches wouldn't affect any device or software at all...

Link to comment

Hi.

IN THE THINGS THAT YOU WANT TO ADD, I WOULD LIKE...

Cache personal note

Favorite points

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.

 

VISITED BUT UNATTEMPTED

This one is a bit hard to explain, but it can have an influence on the GPX file content.

 

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.

 

TKS

c1954m

Link to comment

 

VISITED BUT UNATTEMPTED

This one is a bit hard to explain, but it can have an influence on the GPX file content.

 

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.

 

TKS

c1954m

 

So you're asking for a brand new log type?blink.gif

 

And what's the difference between that, a DNF and a write note?

 

Also, I agree that additional waypoints should be kept separate from the cache waypoints. Some people do like to keep their GPS map clear of the additional clutter, and I don't see any problem with having to put two files onto a GPS.

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