Clearly separate input and output options in the documentation

[jidanni]

Let's take
https://www.gpsbabel.org/htmldoc-development/fmt_kml.html
https://www.gpsbabel.org/htmldoc-development/fmt_unicsv.html
we have to look carefully at each option, to tell if it is for input, or
output.

Perhaps each such page should group them into two groups, with a
<HR> (horizontal rule)
between the two groups.

Here is an example of the old bad way:

lines option
Export linestrings for tracks and routes.

When this option is nonzero, GPSBabel draws lines between points in tracks and routes. The default value for this option is 1, which causes lines to be drawn by default. To disable line-drawing, specify lines=0.

Hmm, "draws". So this must be an output option: we are to use

• -o kml,lines=1

not

• -i kml,lines=1

But things would be much clearer if each documentation page were split into a top half talking about input options, and a bottom half talking about output options. Yes, and maybe a third cross-gender option section.

Actually on https://www.gpsbabel.org/htmldoc-development/fmt_unicsv.html
I found a line that looks like my <HR>, an informal separator:

On the output side unicsv writes fixed number of columns (waypoint index, latitude...

[tsteven4]

I agree that documenting if a format option effects the reader, the writer, real time positioning, or combination of those, would be an improvement. Volunteers?