Tuesday, October 21, 2008

Polyline editor, csv output

A polyline editor is the first page that uses the CSV parser of the last post. At least I have not heard of any other.

The online editor uses the GPolyline.enableDrawing() method that came with api v2.111. The behaviour is similar to MyMaps. The line data is printed on a textarea in CSV format.

The csv parser is used for redrawing the polyline from generated code. You can come back with your csv file and go on editing.  That is a client side application aka web page. So you have to copy/paste the cvs text to your own text editor and save it.

Why csv? The reasons are still the same as they were in 1967.  It is still the interchange format with widest support. Also people are asking for it. It is the easiest to understand and edit. You can use it with any character set. A syntax error will not corrupt the whole file. The list goes on..

There is no csv standard. The concept is so simple that there was never a need for a written standard. Instead there is an informational RCF document 4108 from 2005!

The data validation I am using at the moment is super simple. If either of the excpected coordinate cells includes NaN data, the whole line is skipped. You don't even need a separate empty line skipping. I have not managed to write a bad line that would confuse the other lines.

The current parser is even slightly simplier than the one in previous post. I will not update the previous post. See the source of the editor page.

A series of csv based pages follows.

No comments: