Gpx Application Developers

December 24, 2005

The only thing that comes to my mind without reading the entire thread is that by combining data into one field you then have to parse it in the applications.

GCXXXX-1-PARKING

It seems that these should all be attributes in xml instead of one large field.

UrlName being PARK, then URLOrder could be 1 or 2

5.3k · December 24, 2005

If I sorted them in the correct order in the GPX file would that be enough?

Yes, that would work for me at least.

1.1k · December 24, 2005

It seems to me that gpx files have in the past adhered to xml standards. Xml files are essentially databases. Gpx files as such are databases and each record is one geocache and these are identified as <wpt> ... </wpt>. The new proposal breaks that concept.

It would seem to me that the proposed coordinates are fields of records in the database and should thus be identified with new tags in the same name space as other geocaching field names. I'm sure you are aware that the minute you release this, folks will come with all sorts of new geo-items to include at particular coordinates. So anticipating the ability to accommodate this would maximize the felxibility. I would suggest creating a new section

<Groundspeak:Locations>...</Groundspeak:Locations>

within the record in a similar manner to how the logs are coded.

Here is what I envision for my cache GCKAZD Arboretum Geocaching Tour which has lots of extra coordinates that would be great to be accommodated (I can see the same thing for some long hikes where the cache owner wants to provide info as to what to do at certain locations).

<wpt lat="38.5333333333333" lon="-121.748333333333">
   <time>2004-09-03T00:00:00.0000000-07:00</time>
   <name>GCKAZD</name>
   <desc>Arboretum Geocaching Tour by Hynr, Multi-cache (1.5/1)</desc>
   <urlname>Arboretum Geocaching Tour</urlname>
   <sym>Geocache</sym>
   <type>Geocache|Multi-cache</type>
   <Groundspeak:cache id="165462" available="True" archived="False" xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0">
     <Groundspeak:name>Arboretum Geocaching Tour</Groundspeak:name>
     <Groundspeak:placed_by>Hynr</Groundspeak:placed_by>

...descriptions...logs...TBinfo...then the coordinates as follows:

     <Groundspeak:Locations>
       <Groundspeak:Waypt lat="38.5333333333333" lon="-121.748333333333">
           <Groundspeak:type>PRK</Groundspeak:type>
           <Groundspeak:hidden>false</Groundspeak:hidden>
           <Groundspeak:description>Parking</Groundspeak:description> 
           <Groundspeak:Text>This is a parking garage; park only in spaces marked visitor; cost is $6 per day</Groundspeak:Text>	
       </Groundspeak:Waypt> 
       <Groundspeak:Waypt lat="38.52" lon="-121.74">
           <Groundspeak:type>OTH</Groundspeak:type>
           <Groundspeak:hidden>false</Groundspeak:hidden>
           <Groundspeak:description>Other: RV parking</Groundspeak:description> 
           <Groundspeak:Text>This is location where large vehicles can park with assurance of being able to turn around</Groundspeak:Text>
       </Groundspeak:Waypt>
       <Groundspeak:Waypt lat="N 38 31.970" lon="W 121 45.256">
           <Groundspeak:type>POI<Groundspeak:type>
           <Groundspeak:hidden>false</Groundspeak:hidden>
           <Groundspeak:description>Point of interest 1<Groundspeak:description> 
           <Groundspeak:Text>Torrey Pines </Groundspeak:Text>
       </Groundspeak:Waypt> 
       <Groundspeak:Waypt lat="N 38 31.648" lon="W 121 45.848">
           <Groundspeak:type>S01<Groundspeak:type> 
           <Groundspeak:hidden>false</Groundspeak:hidden>
           <Groundspeak:description>Stage 1<Groundspeak:description> 
           <Groundspeak:Text>Find small white sign and get 3-digit number. This number is  X </Groundspeak:Text>	
       </Groundspeak:Waypt> 
       <Groundspeak:Waypt lat="N 38 31.748" lon="W 121 45.824">
           <Groundspeak:type>POI<Groundspeak:type> 
           <Groundspeak:hidden>false</Groundspeak:hidden>
           <Groundspeak:description>Groundspeak:description>Point of interest 2<Groundspeak:description> 
           <Groundspeak:Text>Surprise - creepy spot </Groundspeak:Text>
       </Groundspeak:Waypt>

...snip... actual cache has several other coordinates...

     </Groundspeak:Locations>
   </Groundspeak:cache>
 </wpt>

I have, of course, invented the namespace as I went along. You should use whatever field names feel right. In my example above I envision subfields of Locations as such: type would be codes of your design, OTH would be "other"; description would be a short bit of text provided by the cache owner, Text would be a description (suitable for downloading into GPSrs that can accommodate it).

Edited December 24, 2005 by Hynr

9.4k · December 24, 2005

It seems to me that gpx files have in the past adhered to xml standards. Xml files are essentially databases. Gpx files as such are databases and each record is one geocache and these are identified as <wpt> ... </wpt>. The new proposal breaks that concept.

No. It actually doesn't. If you wish to question how XML documents actually work (and enjoy being schooled in the process), post a new topic. Although we have been briefly discussing the new addition this pinned topic is meant as a temporary location for notifying developers of changes to the GPX files.

5.3k · December 24, 2005

I am on vacation and reading things in "fly by" mode, but I'd have to disagree with Hynr's proposal. (Sorry, dude.) He's right that so far there has been a 1:1 relationship between waypoints and caches. But changing this doesn't mean we should treat everything as a new fundamental data type. Based on Jeremey's description, this is still a plain ole' waypoint. (And I object to "GPX files are databases....where each <wpt> is a geocache" but that may be hair splitting. GPX files are GPX files. Pocket Queries are GPX files. Geocaches may be represented in PQs and thus GPX files. Not all GPX files are geocaches - but let's not get hung up on that right now.)

By stuffing simple positional information in a private namespace, we'd make it inaccessible to anything that didn't actually grok that namespace. So if you wanted to pull a cache - with parking coords, multi stages, etc. - into, say, ExpertGPS or GPSBabel to convert to your favorite mapping thingy, that information would be lost. Since a simple position <wpt> tag would be readable by those things, that seems preferable to me.

I have minor issues with some of the details presented. For example, relying on the ordering within a file is big problem for those of us in, say, the merging and filtering business. GPSBabel may rearrange the order of wpts in a file during those operations. Also, I don't have the GPX specs in front of me (OK, I'm on the beach and tired and don't feel like looking it up) but <name> was intended to be the name as represented in a GPS receiver. By stacking the deck with GCabcd-BLAH you're increasing the odds of a name collision on units with limited waypoint name lengths. Making it BLAH-GCabcd, you'd stack the deck so that when the names are truncated they'll still be unique. I'd also have to think about how this interacts with GPSBabel's -s option - we use that to toss the GCabcd names and give sensible names from <cmt> or <desc> and having a file where this is desirable for most wpts but maybe not all might lead to some suprise.

BTW, what _is_ this thread, anyway? Is it announcement of things for developers or discussion of proposed ideas or details of the sandbox thing or what?

December 24, 2005

By stuffing simple positional information in a private namespace, we'd make it inaccessible to anything that didn't actually grok that namespace. So if you wanted to pull a cache - with parking coords, multi stages, etc. - into, say, ExpertGPS or GPSBabel to convert to your favorite mapping thingy, that information would be lost. Since a simple position <wpt> tag would be readable by those things, that seems preferable to me.

I was going to say I could argue it both ways. The problem is you still need a reliable way to realize that multiple <wpt>s are related. There are two ways of doing that: hierarchically (Hynr's proposal which was my gut reaction too, but I also figured out quickly that existing tools couldn't pull the data automatically) or relationally. Right now, the only way to relate the waypoints together is to realize that the <name> tags begin with the same prefix. It would be sort of helpful if in addition to that there was a field (probably in the Groundspeak namespace, though it may be possible in raw gpx space but I haven't looked) to "relate" the new <wpt>s to the old. Something like <Groundspeak:augments>GCXXXX</Groundspeak:augments> would at least allow easier searching using XML tools without having to resort to full xpath/regexp usage which is more intensive.

5.3k · December 24, 2005

I am gonna go on record as disgreeing with Hynr, too. Sorry, dude; I just don't like the idea of nested waypoints.

One neat thing about geocaching GPX files is that they can be read by non-geocaching aware applications and they still work just fine. The proposed new method would preserve that property while letting the apps see all the waypoints. And that's a Good Thing.

I think that the "right" way to approach this is, unfortunately, to use the private namespace, pretty much in the way Yamar has proposed. By "right," I mean the way that is most congruent with how GPX files are intended to be used.

In this case, a waypoint that was entered as an "extra" waypoint in a cache would have just one additional Groundspeak-specific tag. Something like this:

<wpt lat="37.31745" lon="-122.144883">
  <name>P1J1F6</name>
  <desc>Parking Coordinates for cache GCJ1F6</desc>
  <Groundspeak:cache_link id="126550" wpt="GCJ1F6" idx="1">
</wpt>

All the information required to link this waypoint to the cache, including the sort order, is in the <Groundspeak:cache_link> tag. In the example above, "id" is the id attribute of the Groundspeak:cache tag, while the "idx" attribute is the sort order index for this waypoint among all the waypoints linked to that cache.

This method allows at least the possibility of keeping the waypoint name lengths short while ensuring uniqueness.

Edited December 24, 2005 by fizzymagic

1.9k · December 24, 2005

In this case, a waypoint that was entered as an "extra" waypoint in a cache would have just one additional Groundspeak-specific tag. Something like this:
<wpt lat="37.31745" lon="-122.144883">
  <name>P1J1F6</name>
  <desc>Parking Coordinates for cache GCJ1F6</desc>
  <Groundspeak:cache_link id="126550" wpt="GCJ1F6" idx="1">
</wpt>
All the information required to link this waypoint to the cache, including the sort order, is in the <Groundspeak:cache_link> tag. In the example above, "id" is the id attribute of the Groundspeak:cache tag, while the "idx" attribute is the sort order index for this waypoint among all the waypoints linked to that cache.

This looks like the best incarnation of this idea yet.

A question though... would this be a selectable thing for a PQ, something that we wouldn't really have to get?

AND

would these points count against our 500?

9.4k · December 24, 2005

BTW, what _is_ this thread, anyway? Is it announcement of things for developers or discussion of proposed ideas or details of the sandbox thing or what?

This thread has turned into the basic title "watch this space" - since its creation it has been used to announce new features that developers need to be aware of. Feel free to split this off into another topic.

5.3k · December 24, 2005

It also occured to me last night that the concept of sequence that keeps coming up may be a dropped beat. GPX -indeed, navigation in general- has a concept of sequenced positions (waypoints); they're called routes. I know that may be a bigger step than we'd want to take here, but if you're trying to ensure you navigate from A->B->C->D, then representating that as a route instead of a set of sequenced waypoints may very well be worthwhile.

Oh, and since I didn't say it above, I do welcome this feature.

December 24, 2005

I think that the "right" way to approach this is, unfortunately, to use the private namespace, pretty much in the way Yamar has proposed.

Exactly, so thanks for fully flushing it out with a much better example than I gave!

The one thing that will make it problematic will be predicting how many caches I need now ;-) I frequently order 500 from one area, 450 from another (assuming I have 50 or so existing waypoints I want to keep). I wish I had a gps with unlimited memory... I'd rather have the extra waypoints and keep this problem though (which I can deal with; getting the extra waypoints was a harder problem).

Actually, Jermey, shouldn't it be an option that you could turn off the extra wpts? On by default makes sense, but i could see some interesting person not wanting the others...

[A better option, but would require more work, would be an option that allowed either the current style or Hynr's ;-]

5.3k · December 24, 2005

First, if this should be a separate thread, a mod should split it out so we can keep the context. It might be Jeremy is the only one who can do that to this particular thread...

Second, I think the task of reducing the waypoint count should fall to the applications reading the GPX file. I don't believe they should be optional. That keeps the user interface simple and avoids all the problems that could occur if someone assumed that they were there when they were not.

Third, I think I want to modify my proposal slightly, to something more like this:

<wpt lat="37.31745" lon="-122.144883">
 <name>P1J1F6</name>
 <desc>Parking Coordinates for cache GCJ1F6</desc>
 <Groundspeak:cache_link id="126550" idx="1">Extra Text for link</Groundspeak:cache_link>
</wpt>

That keeps everything in a single, compact extension. You may note I removed the "wpt" attribute. It was redundant, since all geocaches are guaranteed to be uniquely identified by their ID; using the waypoint name is not as consistent with the design of the GPX extensions.

9.4k · December 28, 2005

I posted a new discussion area for the multiple waypoints option so this one can continue to be used to notify users of changes to the GPX file format.

January 14, 2006

i see lots of people saying that they would like to be on the mailing list, but is there one?

anyway i would like to be on the list

9.4k · March 17, 2006

Adding a new log type:

Update Coordinates

The new log type will be for the owner of the listing to use when they have to move or adjust the coordinates of the listing. It's a good way to show a history of changes to the cache listing and notifies users when the change has been made.

This addition will most likely occur next week.

9.4k · May 22, 2006

We're adding a new cache type: "Mega-Event Cache" - this will be only for the geocaching events that have the following:

1. A minimum of 500 Attendees

2. Groundspeak listed as a sponsor of the event

We'll be launching the new type for Geowoodstock 4. These features will eventually be available for this cache type:

1. A Special Icon

2. Appear on All State Pages (and country pages)

3. Appear on Calendar for one year prior to event

5.7k · May 22, 2006

1. A Special Icon

SPECIAL ICON!?! Now you tell us! Dang, I wasn't planning on going, but now...

May 23, 2006

i see lots of people saying that they would like to be on the mailing list, but is there one?

anyway i would like to be on the list

Me too!

9.2k · May 24, 2006

i see lots of people saying that they would like to be on the mailing list, but is there one?

anyway i would like to be on the list

Me too!

I would recommend subscribing to this topic using the forum tool provided for that purpose. You'll then get e-mail notices when Jeremy posts an update to this thread.

8k · May 24, 2006

i see lots of people saying that they would like to be on the mailing list, but is there one?

anyway i would like to be on the list

Me too!

I would recommend subscribing to this topic using the forum tool provided for that purpose. You'll then get e-mail notices when Jeremy posts an update to this thread.

The only notices I ever got were people asking to be added to the mailing list. So I unsubscribed from this topic.

May 31, 2006

Since the sandbox is not yet up, we will be adding a new size "mini" to the list of supported sizes for caches. This is based on the continuing request to have a size between Micro and Regular.

What about 'nano'? You have to admit that there is quite a difference between the nanos and micros. (That is, in addition to "mini" or "small".)

Edited May 31, 2006 by Team Smokey

June 1, 2006

2 year late is better than never.

Please add me to the list of gpx developers. Thanks!

Paul

July 29, 2006

my custom GPX import tool wasn't working with this week's local pocket queries and upon investigation I found this in the record for cache GCNBGG:

<Groundspeak:travelbugs>

<Groundspeak:travelbug id="47085" ref="TBB7ED">

<Groundspeak:name>Siebenstein</Groundspeak:name>

</Groundspeak:travelbug>

<Groundspeak:travelbug id="150726" ref="TB24CC6">

<Groundspeak:name>Boomer</Groundspeak:name>

</Groundspeak:travelbug>

<Groundspeak:travelbug id="154488" ref="TB25B78">

<Groundspeak:name>Blue Heart Bear</Groundspeak:name>

</Groundspeak:travelbug>

<Groundspeak:travelbug id="154488" ref="TB25B78">

<Groundspeak:name>Blue Heart Bear</Groundspeak:name>

</Groundspeak:travelbug>

</Groundspeak:travelbugs>

also in the record for GCH3RA:

<Groundspeak:travelbugs>

<Groundspeak:travelbug id="31312" ref="TB7A50">

<Groundspeak:name>Gorillaver</Groundspeak:name>

</Groundspeak:travelbug>

<Groundspeak:travelbug id="31312" ref="TB7A50">

<Groundspeak:name>Gorillaver</Groundspeak:name>

</Groundspeak:travelbug>

</Groundspeak:travelbugs>

and yet again in the record for GC7C40:

<Groundspeak:travelbugs>

<Groundspeak:travelbug id="27659" ref="TB6C0B">

<Groundspeak:name>Team Shuey Racer</Groundspeak:name>

</Groundspeak:travelbug>

<Groundspeak:travelbug id="27659" ref="TB6C0B">

<Groundspeak:name>Team Shuey Racer</Groundspeak:name>

</Groundspeak:travelbug>

</Groundspeak:travelbugs>

These were in 3 different PQs and my app threw an error on each so there could have been more.

My question is: is this a bug I'm going to need to watch for or should I start playing the lottery?

1.8k · September 5, 2006

2 year late is better than never.

Please add me to the list of gpx developers. Thanks!

Paul

Ditto for me. Thanks!

9.4k · October 17, 2006

There will be a change to the log type "Archive (show)" and "Archive (no show)" in the next two weeks. They will both become "Archive"

Please update your programs to address this change. Thanks!

October 19, 2006

Hello Guys.

Pls add our Projectgroup to the gpx developers so we can implement some geocaching support in our application ( http://sourceforge.net/projects/jgt-project )

Bye.

October 19, 2006

I've started writing some code for various functions. I am very interested in this topic. Thanks for starting it.

9.4k · October 30, 2006

There will be a change to the log type "Archive (show)" and "Archive (no show)" in the next two weeks. They will both become "Archive"

Please update your programs to address this change. Thanks!

The text was changed today.

December 4, 2006

present

February 10, 2007

I am not sure if this is the correct place to ask this question, but it is a very simple one: When one queries in a zip code for a new location, local caches are listed in order of distance starting with the closest. Where is that measured from? The P.O.? The geographic center of the zip code?

Thanks,

DiegoDooleys

5.2k · February 10, 2007

When one queries in a zip code for a new location, local caches are listed in order of distance starting with the closest. Where is that measured from? The P.O.? The geographic center of the zip code?

This really isn't related to GPX, but to answer your question, it's often none of the above, but usually close to the center. After you do a zip code query, click the "map it" link in the upper-right corner, and the resulting page will show the "center" and have the coordinates in the URL.

February 10, 2007

Thank you for answering. I have also just reupped my membership which greatly increases mapping power.

DiegoDooleys

When one queries in a zip code for a new location, local caches are listed in order of distance starting with the closest. Where is that measured from? The P.O.? The geographic center of the zip code?

This really isn't related to GPX, but to answer your question, it's often none of the above, but usually close to the center. After you do a zip code query, click the "map it" link in the upper-right corner, and the resulting page will show the "center" and have the coordinates in the URL.

March 10, 2007

Hey, put me on that mailing list for developers, also any links that may be handy for development for caching? (Specifically I would like to see some Palm based GPS framework/api, as well as any api/framework for working with various GPS related file types such as .loc, .gbx, etc. Thanks!

April 3, 2007

Hey guys,

Has there been traction on the creation of the sandbox server? Initially announced August of 2004, I haven't seen anything to indicate that such a server has been created, or whether the initiative to create the server has since died.

Could we please get clarification from TPTB? In the absence of information, people tend to make stuff up. I'd rather just skip to the accurate information.

Thanks for your candor,

Marc (The Nomad)

22.1k · April 3, 2007

This is still a desired feature addition; however, the developers want to get the main website running efficiently before opening up the doors to additional traffic from third party apps hitting the database. Thanks for your patience and understanding.

May 25, 2007

I ran into an interesting problem, with both Easy GPS, and GPS-Babel..

I mainly use GPS-Babel to translate massive (2700+ entries) .LOC files, to DeLorme Draw (.AN1) so I can enter the caches, by name, to my eTrex Legend. But, When I translate the draw file back to .LOC format,

it somehow becomes corrupted.. Because, if I try to load the .LOC file, back to .Draw (.AN1), it reports an error, if the cache description (name, etc.) contains any quotes, or <>{}[] symbols. The same line errors appear if I try to load the back-converted .LOC with Easy GPS. I can't seem to figure why GPS-Babel creates the odd .LOC file.. After all, it should be a 1-2-1 convertion (from type 1, to type 2, back to type 1 again.)

Stephen (gelfling6)

5.3k · May 26, 2007

This thread is the wrong place to report problems with a specific piece of software. Please follow up in the support group for that program.

The assertion that converting from X to Y and back to X is always a lossless operation is false. Why you would bounce .loc through Delorme - espeically through .an1 - to send to a Legend is kind of mysterious, too.

May 27, 2007

This thread is the wrong place to report problems with a specific piece of software. Please follow up in the support group for that program.

The assertion that converting from X to Y and back to X is always a lossless operation is false. Why you would bounce .loc through Delorme - espeically through .an1 - to send to a Legend is kind of mysterious, too.

editing, mainly..for the back-forth conversion.. But, since this is the wrong thread, I'll end here.

August 26, 2007

I know its a long time, but please add me to the developers list. Thank you so much!

August 26, 2007

I know its a long time, but please add me to the developers list. Thank you so much!

It's probably time to remention that there isn't a developers list that anyone knows of. Groundspeak hasn't responded on this thread to actually state this and has been fairly silent about the whole thing in general. It probably is worth adding your name here, none the less, but don't be surprised when you don't get some notification that you've been added to a development mailing list.

August 26, 2007

I know its a long time, but please add me to the developers list. Thank you so much!

It's probably time to remention that there isn't a developers list that anyone knows of. Groundspeak hasn't responded on this thread to actually state this and has been fairly silent about the whole thing in general. It probably is worth adding your name here, none the less, but don't be surprised when you don't get some notification that you've been added to a development mailing list.

I always assumed that posting to this thread was effectively adding your name to the list because then you would (by default) get notified of anything they announce here.

This thread is the list and the announcements.

1k · August 28, 2007

I always assumed that posting to this thread was effectively adding your name to the list because then you would (by default) get notified of anything they announce here.

This thread is the list and the announcements.

I'm not sure what everyone means by "adding names to a list" (this or other ones). Click on "Options" in the upper right corner of the page (scroll up to the top first), then click on "Track this Topic". Then you'll get notifications when new posts are added to this topic, including those of people asking to have their names added to the list.

Edited August 28, 2007 by Kai Team

August 28, 2007

I'm not sure what everyone means by "adding names to a list" (this or other ones). Click on "Options" in the upper right corner of the page (scroll up to the top first), then click on "Track this Topic". Then you'll get notifications when new posts are added to this topic, including those of people asking to have their names added to the list.

And without notifying everyone else that you're just saying "me too".

4.4k · October 10, 2007

I am here,for what good it does me.

I just like to keep updated.

Thanks

9.4k · October 10, 2007

We will be adding a new log type within the next 1-2 weeks.

Needs Attention

This will be a Reviewer and Administrator only log type for posting an attention notice to the cache listing owner and to the community on issues with the cache listing.

This will also add a "Needs Attention" attribute to the cache listing.

October 10, 2007

Just out of curiosity what would normally prompt an admin or reviewer to know the cache needs attention?

Once a cache is published how often do reviewers monitor logs and other feed back?

Also does everyone see the attention notice or just the cache owner?

Finally to clear the attention flag does the current/existing process for clearing maintenance also clear this one?

July 15, 2008

I don't get the WereIgo interface. I mean, what are they supposed to be like, how do you do them, etc? The website was VERY uninformitave and I don't know much about them. Could I get the lowdown on these things?

July 19, 2008

Over on the far right of the geocache listing web pages there are check boxes to select two or more geocaches and download that info to your computer.

Is there any way you could also add another button at the bottom of the web page to download the selected, checked, geocaches as a group from the web page directly to the Garmin GPS unit?

Instead of having to download them each individually to a Garmin GPS unit.

Trying to download each geocache individually from the web page to my Garmin Colorado 400t GPS is a real pain!

Also, I have had problems with downloaded geocache gpx files. Either the Garmin Colorado is not processing the gpx file properly OR the gpx file is not constructed properly.

Some geocache gpx files do not register or deliver the coordinates to the unit and thus the GPS unit will not provide distance and bearing to the geocache! ie - the compass or the map will not point to the cache location!

Thanks <_<

July 20, 2008

I would like to be on this mailing list as well, assuming you are still doing it. Thanks.

July 26, 2008

... please shout out so I know you're here.

Presente!

Gpx Application Developers

Recommended Posts

Join the conversation