[Gpsbabel-code] Architecture-type question

[Ron P. <ro...@pa...>]

It has come to my attention that the kml writer supports an option 
called "line_width."  This is the line width in pixels.

an1 also supports that option, unofficially. That is, the field exists, 
but there's currently no way to change it.  It would also be the line 
width in pixels.

Assuming I wanted to translate a KML file to an AN1 file, what would be 
the best way to preserve the line width and other useful parameters - 
like line color - that also translate well between the two formats?

I could augment struct waypoint, but the general trend has been to make 
that struct smaller, not bigger.

I'm sorely tempted to create an fs struct for each of the various 
parameters, so that anyone who understands line width can inquire as to 
whether the record at hand has one or could add one to any record it 
reads, but I think down that road lies madness.

Alternatively, I could give KML its own fs struct that holds line width, 
color, etc. (which would make the kml merge case happier in any event, 
so I think it should be done regardless.)  Then I could make an1 
recognize kml's struct, and kml recognize an1's struct.  Bleah.  Down 
*that* road lies a little thing graph theorists like to call K_n.

The best solution I've come up with is a "line presentation" fs struct 
that encodes width and color.  That still feels hokey; what if a format 
only supports color but not width?  Do we need flags to say what things 
in the struct are valid?

Any other suggestions?

--