Sorry Eric, I forgot to add that part of the documentation since the CSV capability was added pretty much at the last minute. Here are the comments from the code itself in the src directory:

...the path to the resource must end in one of: .shp, .csv, and .tsv for us to be able to do anything with it. However, in the longer run I hope to implement things like using a dsn to specify an ArcSDE server or PostgreSQL database... How exactly that will work I have yet to determine but this seems like the best way to 'future-proof' the spec.

In the event that you are passing it a CSV or TSV file, the method will attempt to parse the file based on whether it was called by the Lines or Points class.

If called by the Points class then it will assume that there is only one x/y coordinate pair. If called by the Lines class then it will assume that there are two x/y coordinate pairs.

The assumption is that there is a header row that can be used to figure out what fields are where. So the x-coordinate will be based on any column name matching 'x', 'x1', 'x2', 'lon', 'long', 'longitude', 'easting'; and the y-coordinate will be based on any column matching 'y', 'y1','y2','lat','latitude','northing'. I'm reluctant to add other

patterns, but this could be done for good reason.

From there, we look for two other possible field names: 'label' or 'z'. 'z' is assumed to refer to some kind of numeric value, although having written that I suppose that a good change for the next release would be to allow a z-elevation and a separate value. 'label' is assumed to refer to a String of some kind (e.g. a city name).

I'll try to add an example of how to use CSV files to the downloadable zip file later today (got a meeting this morning that will run through lunch) and post that for the end of the day.

Hope this helps,

jon

P.S. I'll also try to remember to add the zoom+pan implementation that I use to the example PDE file since I'm guessing that that's going to be a common request.