GPX Format. Comments?

1.1k · December 2, 2002

Yes, it's been a long time coming... Please provide feedback on the current GPX format. I added travel bugs and tweaked the XML so it would validate correctly with SaxCount.exe

I have an example using a GPX file generated of caches in my area with travel bugs in them. I don't believe I missed any important data, but let me know if I did. If you load them into EasyGPS or ExpertGPS (current versions) they will show with cache icons (and one will show as cache found since I found it).

If everything looks good I'll be adding this capability to Pocket Queries towards the end of the week. It seems to work quite well but I want to make sure that the first version of the Groundspeak:cache namespace is fine.

Jeremy Irish

Groundspeak - The Language of Location

1.7k · December 2, 2002

Woo hoo! You da man!

Thanks! Now I'll be up late tonight for sure....

8.9k · December 2, 2002

Hmmmm...

I opened this file with EasyGPS, and one thing that struck me is that there's a field "type" that all has "geocache" in it. Not to armchair quarterback anyone, but is it possible for Expert/EasyGPS to put the cache type (virutal, multi, traditional, etc.) in that field without changing the XML?

Markwell

Chicago Geocaching

December 2, 2002

First, let me say that, having now had time to peruse the sample, I am quite impressed and happy with the state of things. If the sample were to become the finalized state, I would be content and quite happy.

That said, and with profuse apologies for re-re-...-opening a rather worn can of worms, I would be remiss if I did not bring up one little thing that I sincerely believe is important enough to merit the frustration of yet another rehash of an old topic. What is it that bothers me about the example?

<Groundspeak:cache id="GC3FED"  available="True" archived="False" xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0">

The extensively discussed (and rehashed) threads in the forums, coupled with quite a bit of pondering, have led me to sincerely believe that it would be beneficial for the "id" to be set to the numerical form of the cache ID. (That is, the very same "?ID=#####" that is the tail of every cache page's URL.) This would, however, require a slight change and another addition to the namespace:

<Groundspeak:cache id="16365" available="True" archived="False"  xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0"><Groundspeak:waypoint>GC3FED</Groundspeak:waypoint>

The benefit of this would be straightforward. The cache id would be a simple, decimal number, and would allow simple sorts and other operations. The waypoint name would be separate, and any changes (whether by Groundspeak people or by individual cachers on their own data -- either of which may happen when GCFFFF rolls by) would be distinct and would in no way affect the cache id field.

(If this makes sense, it might be logical to do the same for travel bugs, if you wanted to be forward-compatible with any future changes; however, the waypoint vs. cache id issue is a present matter.)

Anyway, let me say again how pleased I am to see the current GPX-related information, and please do not be too upset with me for bringing in a shovelful of a thrice-chewed thread. I only want to give some hopefully constructive feedback on what is looking like a very good thing, indeed.

-ClayJar

1.4k · December 2, 2002

The basic yellow Etrex can't use the "Geocache" icon. Will we still be able to upload the file directly to the GPSr without editing the icons?

====================================

As always, the above statements are just MHO.

====================================

1.1k · December 2, 2002

quote:
Originally posted by Markwell:
(I)s it possible for Expert/EasyGPS to put the cache type (virutal, multi, traditional, etc.) in that field without changing the XML?

Multi-Cache

Considering that the namespace indicates what type of cache it is, adding the type to the base GPX isn't really necessary.

I wanted to keep the GPX type as "Geocache" since applications wouldn't have to maintain a list of types which we would have to adhere to. Digging into the XML to retrieve the type solves that problem. I'm also forecasting that people will be creating applications that will do the work for you.

quote:
Originally posted by ClayJar:
<Groundspeak:cache id="16365" available="True" archived="False" 
The benefit of this would be straightforward. The cache id would be a simple, decimal number, and would allow simple sorts and other operations.

I'll accept that. I'll make the ID change to caches. I'll have to modify the schema for travel bugs to have both the ID and name.

Jeremy Irish

Groundspeak - The Language of Location

1.1k · December 2, 2002

quote:
Originally posted by Harrald:
The basic yellow Etrex can't use the "Geocache" icon. Will we still be able to upload the file directly to the GPSr without editing the icons?

My theory is they will just upload to the eTrex as generic points. Go ahead and try it with the example I posted above. It is readable by the latest version of EasyGPS.

Optimally, applications should allow you to map different types with different icons if that icon is unavailable.

Jeremy Irish

Groundspeak - The Language of Location

9.4k · December 2, 2002

I updated the xsd and the example.xml file. Travel bug now has an "id" and "ref" attribute. The id is an integer and the "ref" is the reference name for the travel bug.

The cache ID is now the integer as well. If you wish to reference the cache by its name it is part of the GPX format.

Jeremy Irish

Groundspeak - The Language of Location

December 2, 2002

Jeremy!

I tried to introduce cache names with accented characters in example.xml, and the file did not load into EasyGPS. Maybe I did something wrong. Please try GC980A (Vår Gård Saltsjöbaden)

/Åke

December 2, 2002

quote:
Originally posted by Jeremy (Admin):
Yes, it's been a long time coming... Please provide feedback on the current GPX format.

Great stuff... playing around with it in ExpertGPS 1.2 now...

(odd thing in 1.2: It does not show .xml files as a default file in its file open list. I had to specify .xml files by hand. It opened it fine, its just not listed as an inputable file extension)

So far so good...

1.7k · December 2, 2002

quote:
Originally posted by Ake S:
Jeremy!

I tried to introduce cache names with accented characters in example.xml, and the file did not load into EasyGPS. Maybe I did something wrong. Please try GC980A (Vår Gård Saltsjöbaden)

/Åke

XML is UTF-8 by default. If you're typing characters like the ones above, they won't work with a proper XML parser.

3.5k · December 2, 2002

This is way better that the previous format.

I've been using the XML in the current format and transforming it to HTML with XSLT.

This new format will be a bit tougher but the extra data will be worth it!

Thanks!

quote:
Originally posted by Jeremy Irish:
I updated the xsd and the example.xml file.

I doubt sometimes whether a quiet and unagited life would have suited me - yet I sometimes long for it.

Byron

[This message was edited by 9Key on December 02, 2002 at 07:19 PM.]

December 3, 2002

quote:
Originally posted by Warm Fuzzies - Fuzzy:

quote:
Originally posted by Ake S:
Jeremy!

I tried to introduce cache names with accented characters in example.xml, and the file did not load into EasyGPS. Maybe I did something wrong. Please try GC980A (Vår Gård Saltsjöbaden)

/Åke

XML is UTF-8 by default. If you're typing characters like the ones above, they won't work with a proper XML parser.

http://216.202.195.127/warm.gif

OK, I tried to enter properly utf-8 coded characters (åäö) in the xml-file but EasyGPS did not load the file.

/Åke S

5.3k · December 3, 2002

Yay. I'd somewhat dismissed GPX from Groundspeak, so I'm glad to see its head popping out.

I just fed the sample to gpsbabel. It contains code to deduce icon types from cache info using the Groundspeak extensions. (A virtual is binoculars becuase you "look" at it, a multi is the bunch of grapes because there are a bunch of waypoints, etc.)

Unlike previous sample runs, gpsbabel is tripping on this becuase there are now two forms of "Groundspeak:type" fields. It looks like the thing to do is to add another state to my (awful) state machine in expat to not process those during 'Groundspeak:logs'

I have another Groundspeak parser in perl that'll need to be taught the new log format, too. Other than the log thing, my August era program seems to cope with these OK. (Neither of these cases are a big deal - I expect to adapt to formats in development and expect to do it again.)

How do you handle logs and hints that alternate the rot13 state with square braces?

Along those lines, do you have any textual description of the Groundspeak extensions to GPX? It doesn't have to be formal legalese but it would be handy to those developing programs that understood the Groundspeak extensions.

Thanx!

1.7k · December 3, 2002

quote:
Originally posted by robertlipe:
How do you handle logs and hints that alternate the rot13 state with square braces?

There's one of those in the sample file. The text is all decrypted in the GPX file, with the square brackets still in place.

quote:
Along those lines, do you have any textual description of the Groundspeak extensions to GPX? It doesn't have to be formal legalese but it would be handy to those developing programs that understood the Groundspeak extensions.

What, the schema isn't good enough for you?

Which reminds me... I see an HTML attribute in the GPX schema. Will the query be able to return either HTML or not based on a checkbox, or what?

5.3k · December 3, 2002

How will the user-entered coords be made available in the data file? It's very handy for new caches when the posted coords are, uuuh, suboptimal It's also nice for locationless logs for mapping or duplicate suppression.

9.4k · December 3, 2002

quote:
Originally posted by robertlipe:
How will the user-entered coords be made available in the data file?

I missed that. I'll see if I can add it in today. I'm currently drowning in emails from an apparently very busy caching weekend.

Jeremy Irish

Groundspeak - The Language of Location

9.4k · December 3, 2002

Now, If I add the user defined waypoint, should it be a fully defined GPX waypoint or can I just do this:

This is the easiest way. To create another GPX node would be a pain. Thoughts?

Jeremy Irish

Groundspeak - The Language of Location

December 3, 2002

quote:
Originally posted by Jeremy (Admin):

quote:
Originally posted by Markwell:
(I)s it possible to put the cache type (virutal, multi, traditional, etc.) in that field without changing the XML?

Multi-Cache

Considering that the namespace indicates what type of cache it is, adding the type to the base GPX isn't really necessary.

I wanted to keep the GPX type as "Geocache" since applications wouldn't have to maintain a list of types which we would have to adhere to. Digging into the XML to retrieve the type solves that problem. I'm also forecasting that people will be creating applications that will do the work for you.

I don't understand this answer. Existing applications (including EasyGPS and ExpertGPS) are going to ignore the private Groundspeak::type, and just get Geocache for the multi-cache.

is an open text field - there's no list of "official types". Having Multi-cache or even cache-type-that-we-haven't-even-invented-yet isn't going to hurt any GPX application, and it will certainly make things easier for those geocachers who want to sort their caches by type in EasyGPS and other programs.

I'm in favor of Markwell's proposal.

--

Dan Foster

TopoGrafix: GPS Software, Waypoints, and Maps

http://www.topografix.com/

December 3, 2002

I'd like an option to specify (on geocaching.com) what data should go in each of the following three fields:

GC1234

Jeremy's Wonder Cache

I don't bring a list of geocache ID numbers with me, so it's never obvious that GC1234 on my GPS receiver is "Jeremy's Wonder Cache". Since I use a GPS with long waypoint names and ExpertGPS, I'd rather have my private queries return this:

Jeremy's Wonder Cache

Jeremy's Wonder Cache by Jeremy (1.5)

GC1234

That way, my GPSr would get JEREMYSWON or similar, which would be more meaningful to me in the field than GC1234.

--

Dan Foster

TopoGrafix: GPS Software, Waypoints, and Maps

http://www.topografix.com/

--

Dan Foster

TopoGrafix: GPS Software, Waypoints, and Maps

http://www.topografix.com/

December 3, 2002

Regarding the Geocache vs. J. Random Geocache concept: I am of the firm belief that all geocaches should be of type "Geocache". All my school waypoints are of type "School", although they have "sub-types" specified to label them as "Elementary", "Middle", "High", and "Alternative".

Polluting the designation may be all pretty for those of you who do nothing but cache, but for those of us who'd like to keep lots of different classifications of waypoints in our one GPX-backed database, it falls flat.

Regarding customizing the name, description, et al: That falls squarely in the realm of user choice. Sure, it'd be nice if we could each tell Groundspeak *exactly* what we want in our files, without regard to anyone else, but it's not at all necessary.

Remember, that's the beauty of an open format. If you want to write or use a program that takes your geocaching GPX file and rewrites all the waypoint names, descriptions, et al, it's quite easy to do. We don't need to have everyone's little changes in Groundspeak's downloaded GPX file; we can add them ourselves! (I for one would love to keep a saved waypoint file on my MeriGold's SD card with all the waypoint comments translated into pig latin... see if anyone borrows my MeriGold at a gathering again! HA! )

9.4k · December 3, 2002

ClayJar explained it better than I could. We already have descriptive tags like and so in my mind the tag should contain strongly typed names such as Benchmark and Geocache (and School, etc).

As for the tag I changed it to since it isn't a true GPX tag. Call me lazy but you can get the data provided that way.

Customizing the descriptive tags for each user is an interesting idea, though I would prefer to keep it standard, so anyone creating applications against the published Groundspeak:cache namespace knows what each tag contains.

Jeremy Irish

Groundspeak - The Language of Location

9.4k · December 3, 2002

I added to the example.xml and cache.xsd so they validate against each other. I also added a locationless cache GPX file so you can see the in action.

Jeremy Irish

Groundspeak - The Language of Location

5.3k · December 3, 2002

I'm reluctant to get involved in a scuffle between Mr. GPX and Mr. Geocaching.com but I'll try.

The reality is that the name squishing has to be done at the very end of the software chain. I have a friend that has five GPS models, each with different waypoint naming rules. Does he need five pocket queries? Ick. You really want the software on the end to make this decision. (Dan, your stuff really does a pretty good job at this *if* you tell it to ignore the provided shortname.)

I implemented this same kind of thing in gpsbabel a while ago. Your very example, once the typo is fixed, would go to a Magellan 330 or better as:

$PMGNWPL,0.000,S,00000.000,W,0000000,M,JermysWn,Jeremy's Wonder Cache,a*79

For a Garmin with D109, the cache name would be JEREMYSWONDERCACHE and the comment (would go intact) A Banana or a 315 would get JERMYS. It's "mnemonic enough".

You just need a switch in your code to tell it "the in this GPX file is stupid and should be ignored; I can make up my own from or better"

Having the cache type in the "waypoint type" is, again, tempting but the reality is that in order to really build the Perfect Geocaching Software, you're going to have to know to grok the Groundspeak namespace anyway. (This does NOT give Brother Irish encouragement to go nuts with "Multi Cache", "Multicache", "Multi-cache" all on the same page.) Once you've teased apart the GPX, sticking the full cache name, the diff/terr, and the name of the placer in the receiver's waypoint comment field isn't that hard to do and it's WAY helpful in the field. (Rats, now I'm giving away my secrets for the big numbers. )

Yes, Jeremy, I think your solution of log_wpt looks fine to me. It isn't a full-fledged waypoint and it'd be contrived to consider it one.

9.4k · December 3, 2002

quote:
Originally posted by robertlipe:
(This does NOT give Brother Irish encouragement to go nuts with "Multi Cache", "Multicache", "Multi-cache" all on the same page.)

This would be a good time to discuss how folks want it typed. It will be standard since I pull it from a cachetype database table.

The first *should* never be seen, and the locationless cache type is the only one I could see changed (though the dash does look irregular when listed with the rest).

Not Categorized

Traditional Cache

Multi-Cache

Virtual Cache

Letterbox Hybrid

Event Cache

Unknown Cache

Project APE Cache

Webcam Cache

Locationless (Reverse) Cache

Once it is "official" I have to start supporting the namespace, so please chime in now if you have any input.

Jeremy Irish

Groundspeak - The Language of Location

1.1k · December 3, 2002

Man, I wish I could understand just what the heck you guys are getting at. As long as when I get my newest caches I can understand, or at least my GPSR can, where the heck they are, then I will be a happy camper. Anyone want to come over and explain the meaning of life? It looks to me like it would be as easy to explain as the above conversation.

5.3k · December 3, 2002

I don't care how they're spelled becuase I'm going to decompose them to an enumerated type for processing anyway. Pick one, doc it, and be consistent with it. (I had a problem when I saw two spellings of the "same" type in a file, but I can't recall the details.)

Jeremy, would it help with the "1.0 blues" to go ahead with what you have (which i think really is darned good) but call it 0.9 for a limited time? The software developers could then do our thing and get some real-world experience with the data by putting test software in the hands of the users. I think the data is pretty volatile anyway so we don't have to worry about the data, the xsd, and the software getting too far out of sync. We could even agree that nothing that supported 0.9 would be called anything but "beta" if that'd help.

BTW, why are the time stamps in the logs all exact multiples of an hour? I don't really care as I'm going to throw the times away anyway, but it's a curiosity.

Logscalar, I hope it won't sound condescending if we optimize the discussion to "Smart guys are all over it. They're even agreeing most of the time."

December 3, 2002

First, isn't it somewhat redundant to call a geocache a $whatever cache? It seems to me (of course, I *am* somewhat unusual) that the should be the adjective ("Virtual") to the 's noun ("Geocache"). That way you'd end up with a "Geocache" that is Not Categorized, Traditional, Multi, Virtual, Letterbox Hybrid, Event, Unknown, Project Ape, Webcam, or Locationless (Reverse). It just seems a little odd to me to redundantly call it an Event Cache Geocache.

Second, and possibly a bit more significant, do you have "cache attributes" defined in the namespace? While they're not currently used on Geocaching.com, if you're still working that way, it might be worthwhile to add them to the namespace while it's still not yet "official". Then if you ever add them, it won't require an additional change. (I've got to be thinking about my hydrocaches, after all.) I imagine you'd just do something like:

<wpt>  <Groundspeak:cache>    <Groundspeak:attributes>      <Groundspeak:attribute></Groundspeak:attribute>      ...(etc)...      <Groundspeak:attribute></Groundspeak:attribute>    </Groundspeak:attributes>  </Groundspeak:cache></wpt>

Anyway, just a few more thoughts.

5.3k · December 3, 2002

quote:
Originally posted by robertlipe:

Yes, Jeremy, I think your solution of log_wpt looks fine to me.

Now that I have my software reading logs once again, I'd like to change my mind. I've decided I don't like your log_wpt.

The elements come through as:

          <Groundspeak:log_wpt lat="35.303333" lon="-79.41885" />^M

I'm no XML jock, but I don't think that's legal. (It pretty much blows away expat.)

We probably want something closer to

          <Groundspeak:log_wpt>lat="35.303333" lon="-79.41885"</Groundspeak:log_wpt>^M

do we not?

BTW, we have the same "closing tag marker" thing going on with bounds and

5.3k · December 3, 2002

quote:
Originally posted by ClayJar:
First, isn't it somewhat redundant to call a geocache a $whatever cache?

Yeah, but I degenerate them to an enumerated type and providing my own spellings anyway. (I do all my caching in Klingon just to keep things interesting.)

Other than the additional bytes in the file and on the hose (and believe me, there are bigger redundancies than this) it's merely cosmetic, right?

5.3k · December 3, 2002

quote:
Originally posted by robertlipe:
We probably want something closer to
          <Groundspeak:log_wpt>lat="35.303333" lon="-79.41885"</Groundspeak:log_wpt>^M
do we not?

I don't think so; the way Jeremy did it is more consistent with the way the tag is defined. I'm not sure I understand why it is giving your parser fits.

BTW: Jeremy, you ROCK! Thanks so much for getting this out!

5.3k · December 3, 2002

quote:
the way Jeremy did it is more consistent with the way the tag is defined. I'm not sure I understand why it is giving your parser fits.

It's possible that it's legal, but it's definitely funny looking. is defined in GPX in a pretty

normal way.

...optional wpt thingies, each opening and closing

(thus closing the wpt)

Every other tag follows the pattern stuff while this is . It's toasting expat becuase it's not seeing a closure for blat since there is no .

But I've now offiically exceeded my GPX fun quota for this day. I'll swing at it again later.

December 4, 2002

quote:
Originally posted by robertlipe:
Every other tag follows the pattern stuff while this is . It's toasting expat becuase it's not seeing a closure for blat since there is no .

It shouldn't be toasting expat at all, since it's the correct way to do an XML tag. The trailing slash means that it's an open and shut tag. (Two tags for the price of one.) is basically just shorthand for . (It's like the

tag in XHTML.)

Additionally, the lon and lat *are* attributes of the log_wpt, so they belong in the tag as attributes, not between tags as content. is actually the correct way to do it.

[This message was edited by ClayJar on December 04, 2002 at 04:26 AM.]

1.7k · December 4, 2002

quote:
Originally posted by ClayJar:
is basically just shorthand for . (It's like the

tag in XHTML.)

Or, for a better analogy, the foo tag in XHTML.

9.4k · December 4, 2002

This is legal:

^M

If you can get it to parse through SaxCount.exe (and it's a chore. Believe me!) then it is legal. I also use VB.NET to create an XMLElement so I'm not just assembling a string to look like XML.

log_wpt also mirrors the wpt tag in GPX.

Good idea on making it 0.9 instead of 1.0, I'll do that as well.

As for attributes, you're right. Unfortunately I have an internal dataset that does not yet include the attributes feature (but something I really have to add!) but I can create a placeholder for that logic.

Jeremy Irish

Groundspeak - The Language of Location

9.4k · December 4, 2002

^M

I wanted to mention that my xsd file pretty much categorizes every element as a string. I'm still learning xml so I may have to go back and type each section.

Logscaler: We're just figuring out a way to make GPX both human readable and application readable. People like fizzymagic, ClayJar, and robertlipe have their own ideas how they would like to present cache information, other than the standard web and Mobipocket format.

Jeremy Irish

Groundspeak - The Language of Location

1.7k · December 4, 2002

quote:
Originally posted by Jeremy Irish:
People like fizzymagic, ClayJar, and robertlipe have their own ideas how they would like to present cache information, other than the standard web and Mobipocket format.

And me. Don't forget me. Oh, and I can't believe you used the word "standard" and the word "MobiPocket" in the same sentence. They believe standards are things that happen to other people.

I still have an outstanding question listed above: will there be an option on the search page or whatever other page generates these GPX files to get the cache descriptions in HTML? If so, could you generate a sample file that has HTML descriptions so we can test our utilities with it as well? This might be important because of course HTML will look like XML to a naïve parser.

1.7k · December 4, 2002

Replying to myself: I see that the sample file does have some HTML="true" entries in it, and that they encode the HTML with > and so on. So, let me scrap that question and ask a new one: what governs whether you'll get HTML="true" or HTML="false" on an entry?

1.1k · December 4, 2002

quote:
Originally posted by Warm Fuzzies - Fuzzy:
(W)hat governs whether you'll get HTML="true" or HTML="false" on an entry?

The owner does when they report a cache. It is a checkbox on the "report a cache" web page. Before I added that feature I had to make all previous caches as html=true because the approvers had to provide formatting in HTML for each cache.

BTW, I intentionally said standard Mobipocket to get your hackles up.

Sorry I missed you on that list. fizzy and fuzzy probably confused me.

Jeremy Irish

Groundspeak - The Language of Location

1.1k · December 5, 2002

I decided to leave it as version 1.0 - I added some annotation to the cache.xsd file, and added the attributes tag for when we implement it. I'll follow up in the forums with an attributes topic to discuss which attributes we should make available for caches.

Unless there are any other questions or issues, I'll make the ability to generate GPX files available sometime tomorrow. You'll be able to select it from the dropdown list that currently only shows LOC.

Thanks for everyone's input. I hope I was able to provide the right data in the best format.

Jeremy Irish

Groundspeak - The Language of Location

December 5, 2002

I wrote a quick and dirty perl program to put caches on a DeLorme Street Atlas map. It works for both your new GPX and EasyGPS XML . In SA: file import lat/lon(it likes a .txt extension).

Example perl command:

xml2sa example.xml > example.txt

xml2sa script:

#!/usr/local/bin/perluse XML::Parser;  $p1 = new XML::Parser(Style => 'Subs', Handlers => {Char => &ch});$p1->parsefile($ARGV[0]);exit 0;sub ch {$string = $_[1];}sub name_ {$name = $string;}sub desc_ {$desc = $string;}sub wpt {    my ($p, $e, %atts) = @_;    $lat = $atts{lat};    $lon = $atts{lon};}sub wpt_ {    $desc =~ s/"/'/g;    $name .= " $desc" unless $name eq $desc;    print "$lat, $lon, "$name", 12, 0, 1n";}

December 7, 2002

quote:
Originally posted by Jeremy (Admin):
Unless there are any other questions or issues, I'll make the ability to generate GPX files available sometime tomorrow. You'll be able to select it from the dropdown list that currently only shows LOC.

Well I guess either some issues came up or it isn't tomorrow yet. I studied up on processing XML with Perl (I use module XML::Twig) and my test program is ready and waiting

5.3k · December 7, 2002

quote:
Originally posted by John E Cache:
I wrote a quick and dirty perl program to put caches on a DeLorme Street Atlas map.

As an aside, gpsbabel will do this. It takes more than 20 lines of code to do it, so it's evolved out of 'quick and dirty'.

gpsbabel -i gpx -f blah.xml -o csv -F safile.txt

or use the newfangled pointy clicky draggy droppy stuff.

quote:
...

use XML::Parser;

$p1 = new XML::Parser(Style => 'Subs', Handlers => {Char => &ch});

$p1->parsefile($ARGV[0]);

exit 0;

sub ch {$string = $_[1];}

sub name_ {$name = $string;}

sub desc_ {$desc = $string;}

That's an interesting coding style and one I hadn't thought of. I think it'll do the wrong thing if the name or description legitimately contain html entities (i.e. "Ticks & Poision Ivy") , contain special characters (depressingly common when people cut and paste 'smart quotes' from Word or in i18n cases) or if the tag is split across lines (XML::Parser will issue multiple callbacks so you probably want to push them into a stack or something.)

Still, your example shows how simple processing the majority of the cases can be.

Would anyone be interested in a mailing list and repository of free/open programming projects involving Groundspeak/GPX so we don't all keep doing this from scratch?

December 7, 2002

#!/usr/local/bin/perluse strict;use XML::Twig;my $twig = XML::Twig->new();$twig->parsefile($ARGV[0]);my $root = $twig->root;foreach my $wpt ($root->children('wpt')){    print $wpt->att('lat') . ', ' . $wpt->att('lon') . ', ';    print '"' . (my $name = $wpt->first_child_text('name'));    (my $desc = ($wpt->first_child_text('desc'))) =~ s/"/'/g;    print ($name eq $desc?'"':' '.$desc.'"');    print  ", 12, 0, 1n";}

[This message was edited by AllenLacy on December 07, 2002 at 04:25 PM.]

December 7, 2002

quote:
Originally posted by robertlipe:
That's an interesting coding style and one I hadn't thought of. I think it'll do the wrong thing if the name or description legitimately contain html entities (i.e. "Ticks & Poision Ivy") , contain special characters (depressingly common when people cut and paste 'smart quotes' from Word or in i18n cases) or if the tag is split across lines (XML::Parser will issue multiple callbacks so you probably want to push them into a stack or something.)

Thats why I called it dirty .

I only put in two special cases...so far. SA uses quotes for their label so I substitued ticks. Second my GPS's default waypoint description is the title. If I don't change the default description on my GPS my perl script throws it away.

I think the GPX strings will handle special characters and HTML. After all GPX is a form of HTML. Open an XML/GPX file in your browser sometime.

I hope the parser ignores multiple lines. New lines are only used so we humans can read the code.

quote:
Would anyone be interested in a mailing list and repository of free/open programming projects involving Groundspeak/GPX so we don't all keep doing this from scratch

I'm enjoying the comments(thank you) and discussion here for now. A new version has even been posted. Thanks, AllenLacy.

December 7, 2002

1.7k · December 9, 2002

quote:
Originally posted by Jeremy (Admin):
Unless there are any other questions or issues, I'll make the ability to generate GPX files available sometime tomorrow.

Were there issues? Should we be seeing GPX on the pocket query page now?

GPX Format. Comments?

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment