First!...
if the map(s) are not comming in, be patient, and try the re-load button on your browser. Failing that, try again some other day. The maps are generated in real-time by The Xerox PARC Mapserver which, being in the public domain, tend to be abused by jerks like me! The point here is that it can be, and often is, slow and unreliable. Life is like that, and I have great confidence that both you and I will live. If this were a "mission critical" project, I'd batch generate the images and link them statically...It's not, and even without the graphics, the Hotsprings pages consume 12MB of my web space!

Secondly...
This is simply a very temporary index page describing the "pms" or "Point Mapping Script" that I have developed as a means of learning someting about the programming launguage named "Python."

The purpose of the script is to take a set of data files containing datapoints (lat/lon) and various other information, and produce a set of web pages with maps for each datapoint. Here is a link the HotSprings of the Western U.S. which shows an example of the output. The fact that it would have taken months or years to do this much html work by hand was, in part, the motivation for me to start work on the pms project.

It is worth note that while the collection of pages consumes a fair abount of webspace even without the graphics (which are dynamically generated by the Xerox PARC mapserver...when it is functional), it is completely static. No server-side includes or dynamic html. In short, it should work fine in any webspace, and it is of a simple "flat" filestructure.

Note that the above example is somewhat perliminary. Though I refined and improved the pms more that I had initially anticipated, I can still see many areas for further work. I have generalized it quite a lot with the intention of being able to run fairly generic data sets through, and the design and implementation specifically reflects both an overall ability to modify certain behavious, and hooks for various missing features. For instance, should it become B impossible to use Xerox PARC mapserver url's, only one function needs to be rewritten to switch to another (hopefully :), and when I get around to playing with functional programming, I'll plop in a little code to group close datapoints and thus expand the number which can appear on a state map.

Additionally, the input files themselves contain much information about how the pages are to be constructed. The reason for this is that it should provide a means for others who are not intimately familiar with the workings of the script, the ability to do a lionshare of the "grunt work". If I end up running the script on behalf of others either because they asked nice, or paid me, it is supposed that it will take relatively little effort on my part.

I should also probably note that I initially got some motivation and ideas for this project by looking at the work at http://www.soak.net and at one of the many government sponsered, and very cool earthquake sites that use Xerox PARC maps.

-Tom

www.huppi.com

To Contact Me, pms_codr@_my_last_name_.com