Stuff I Need to Get Motivated to Start Soon

• KML/KMZ/GeoRSS/GPX import/export - It’s pretty easy to display such a URL in a separate KMLLayer, but extracting the vertex locations to display an elevation profile for the path means parsing the XML myself (and raises same origin policy issues). It would appear that what I really need is an upload page that will parse the uploaded file, convert it to an array of locations, serialize that into my DB, and then display a big_peak_map.php URL that includes a new &path_uid query parameter. I guess I’d just support GPX (probably via gpxviewer). I’d probably also include &kml support to simply display a KML file as is, just to make it easier to draw out a path on top of it by hand.

Less Critical Improvements

• Validate/Tidy XHTML/PHP/CSS/KML - I’ve validated all of my XHTML and CSS, but I guess I could take a look at the KML as well (if not the PHP). I could also use something like TIDY to make the source more standard (prettier? unlikely).
• Separate Saddle Details? - The saddle information could be put into its own section on the Peak Detail page.
• Peak Pictures - I fooled around with page backgrounds for the Peak Detail pages, each containing a washed-out picture of the peak. I don’t have pictures of each peak, but I could probably get most of them covered by appealing to the SummitPost.org authors. I need to spend more time figuring out how to efficiently fade the picture borders to white to make these look better. Another approach would be to include a real picture at the top. I certainly want to avoid overlapping the SummitPost.org space, so it would be better to improve Google Earth integration than (for example) to include multiple pictures, or to include pictures with route lines drawn in.
• Analyze Ridge Profiles - It would be cool to demonstrate graphically that the DEM data are not only consistent with the map contours, but that they also provide a more continuous function along the ridge crests, as I have hypothesized on my Methodology page. This would require porting the better part of the RidgeWalker code from C to Java.

Stuff I Haven’t Figured Out How to Make Worth Doing

• Links from VRMC Trip Reports - All of the VRMC trip reports mention peaks. It would be cool to link the peak name to the corresponding Peak Detail page. Unfortunately, though, many of these already link to photos, so I'd have to move the photo links to some other text (descriptive phrases in the reference?) Lots of work for marginal benefit - maybe just try this out with future reports?
• Peak List Controls - Clicking the column headings in the peak lists could sort peaks by rank, name, elevation, and saddle depth (or even whether the climber has climbed the peak). This would be useful only for the failing peaks and (possibly) for climbs pages. I could also display the list within a scrolling area, but I like the way everything is simple when you just display and print the default peak list windows.
• Import/Export Climb Data - I could add an export feature fairly easily, but it probably wouldn't be used much (I hope). An import feature would be complicated by the need to refer to peak UIDs (or names). I could throw up confirmation dialogs, but how much effort is this feature worth? It’s probably easier to just handle import/export requests by hand via phpMyAdmin and BBEdit (as I did for Foo’ball).
• BabbleFish Password Security - phpMyAdmin uses BabbleFish to encrypt passwords before they are sent from client to server. I believe this is a one-way encryption, where the server doesn’t actually know the plaintext version of the password. Instead, the user transmits only the encrypted password, which the server then compares to its encrypted password. Both the JavaScript and PHP can perform the one-way encryption (the latter for providing the user with a temporary password), but neither can reverse it. The problem is that the encrypted password is transmitted in the clear, so custom JavaScript could easily be written to POST the encrypted password and thereby obtain a valid client session ID (it’s just that you can’t use the normal VRMC login.php to do so.) If you’re going to the trouble of packet sniffing to steal the password, writing some JavaScript to submit the encrypted password doesn’t seem like much extra work to me. Real security would appear to depend on enrypting all transmissions back and forth or perhaps some kind of challenge and response during login where the server provides something (unexpected) to the client for it to encrypt using the password. It would have been nice to get some experience figuring this login design pattern out, but it didn’t seem trivial.