gpx2html working

[+fizzymagic]

I've reached the point with my gpx2html.pl Perl script where it's working to my satisfaction. So try it out. It has several neato-keeno features:

• It generates very compact HTML from GPX files. I got 500 caches into an 880K Plucker file.

• It can combine multiple GPX files into one set of HTML files.

• Each cache page contains the description, the last 5 logs, the encoded hint, a link to the decoded hint, and the 5 nearest caches from the GPX file.

• There's a separate page for decoded hints, which you can link to directly from the cache page.

• Summary statistics are given (Last Found date, number of Finds and DNFs in the last 5 logs).

 

I used XML::Twig, so you'll have to get that either from CPAN or I have a copy on my website.

 

Give it a whirl. A page with the necessary instructions is here

[skydiver]

Ok, why did you choose XML::Twig, instead of XML::Simple, or any of the other seemingly billions of other XML modules for Perl?

 

---------------------------------------

"We never seek things for themselves -- what we seek is the very seeking of things."

Blaise Pascal (1623-1662)

---------------------------------------

[+fizzymagic]

I used XML::Twig because it made the most sense to me. I tried XML::Simple (it wasn't) and a couple others.

 

What I've found amusing is that there are at least 3 other people working on GPX parsers that reached the same conclusion independently!

 

It's based on XML::Parser, so it's not terribly fast but it seems quite robust.

 

[This message was edited by fizzymagic on January 11, 2003 at 01:20 AM.]

[robertlipe]

Congrats, and thanx for posting it.

 

I, too, chose XML::Twig after evaluting several of the Perl XML Parsers. Most that I looked at seemed insistent on pushing a lot of state handling and comparisons up into the caller instead of just handing us a tree that could be traversed.

 

There were lots of options so it's not the only choice, but it seemed to be a good one when I studied the options. My only complaint was that it seemed slow.

[+Allen_L]

My reasons (which could be different from other coders)

 

I rejected XML::Simple because it read in the entire XML at once and therefore used lots of memory.

 

I rejected XML::Parser because it was too low level for my taste.

 

I picked XML::Twig because it could read in the information for one Cache, the code could process it then release the memory and process the next cache and so on. It was also usable in a way that made sense to me.

[John E Cache]

Good job! I use XML:simple, but I will look at Twig. The thing I like about posting Perl is that most Perl programmers who have read the Larry Wall Perl books follow the principle of there is more than one way to do it. No right way or wrong way.

 

As LilDevil pointed out, you might want to try the new Perl 5.8 perlio to handle the UTF-8 characters.

 

open OUTFILE, ">:encoding(cp1252)", "palmfilename"; # palm used code page 1252 on OS 3.5open INFILE, "<:encoding(UTF-8)", "gpxfilename";

 

I was going to use substitutions like you, but I read and wrote a gpx file with Perl 5.8 and it sure works great.

 

Keep us posted.

[+fizzymagic]

I love the fact that in Perl there are always many ways to do anything. XML::Parser apparently has some problems with Perl 5.8, and XML::Twig depends on it, so (for now, anyway) 5.8 is out.

 

On another note, I've updated gpx2html to try to make it accessible to non-gurus. First, I made the default so that it processes all GPX files in the directory. That way, most people don't have to worry about command-line arguments. Second, I made a Win32 executable with perl2exe. Anybody without Perl want to test it? If it works, it should be usable by more or less anybody.

[+Allen_L]

I use Unicode::String

 

use Unicode::String qw(utf8 latin1 utf16);my $u=utf8($In);# create Unicode::String $Out = $u->latin1; 

[+Sissy-n-CR]

Works pretty good, but...

 

I got some errors with Plucker and I didn't think to save the log. As a consequence some of the pages didn't load.

 

I like the inclusion of the nearest caches on the cache pages. However, the way we hunt is by looking at the waypoints on the GPS and the waypoints go by waypoint name. On the page your program generates, the nearest caches are by cache name. Could we include at least the hex portion of the cache_ID?

 

CR

 

[+fizzymagic]

quote:

---

Originally posted by Sissy-n-CR:

I got some errors with Plucker and I didn't think to save the log. As a consequence some of the pages didn't load.

---

 

Make sure that you have it set to only include pages from the exact server of the starting point, and have images turned off.

 

quote:

---

I like the inclusion of the nearest caches on the cache pages. However, the way we hunt is by looking at the waypoints on the GPS and the waypoints go by waypoint name. On the page your program generates, the nearest caches are by cache name. Could we include at least the hex portion of the cache_ID?

---

 

Done. Enjoy!

[j3ff]

I love it already and I have not yet used it to go caching with. Just got done loading it into my palm and had no problems at all getting it to work. I did use the premade exe. I have been trying off and on all day to get a mobipocket replacement and your app has been the only one I have been succesful with. THANKS!

[+evergreenhiker!]

I downloaded plucker and tried out your perl program...cool! Things work great so far! I don't know what I did without a pda before! Goodbye paper!

[+GrizzlyRider]

I just found out about your gpx2html today. I downloaded it and I already love it. I have my 2 pocket queries loaded into my Sony Clie and I am about to remove MobiPocket and it's files from it. I just hate how cumbersome MobiPocket is to use when you have a big file.

 

One of the things I would like to see is a way to sort the page by the original sort of Distance from a specified coordinate.

 

Thanks for all the hard work!

[+fizzymagic]

quote:

---

Originally posted by GrizzlyRider:

One of the things I would like to see is a way to sort the page by the original sort of Distance from a specified coordinate.

---

 

It's almost done. I've been working on it for a while, actually. It will work like the ignoring caches and correcting coordinates features; you will have a file with coordinates in it, and it will generate a page for each coordinate set with the distances to every cache.

 

Should be ready this weekend sometime.

[+GrizzlyRider]

quote:

---

It's almost done. I've been working on it for a while, actually.

---

 

I thought I had read something on the download page about that. This is a great utility. You da "fizzymagic" man!

 

One other suggestion. Would it be possible to include icons for caches types to be listed on the index pages and the actual page for each cache?

[+fizzymagic]

One of the ideas of gpx2html is to avoid graphics, because I am trying to make the Palm part as small as possible. So instead of an icon, I would rather use a character, like V for virtual, M for multi, etc. You want those on the index pages, as well as on the "nearest caches," right?

 

The caches sorted by distance from reference locations is done, by the way. You can have as many reference locations as you want; the app generates a new sorted index page for each one.

[+GrizzlyRider]

quote:

---

One of the ideas of gpx2html is to avoid graphics, because I am trying to make the Palm part as small as possible. So instead of an icon, I would rather use a character, like V for virtual, M for multi, etc. You want those on the index pages, as well as on the "nearest caches," right?

---

 

Yes, that sound great to me. Having them in both places is a very good idea. In some future version you might want to consider very small Icons for those of use who use a palm compatibles that have memory cards. (Just a suggestion.)

 

 

As for the version by reference point, I am going to download it right now.

 

Once again, thanks for all the hard work!!!!!