The second idea, for selecting layers from the command-line ... I have to ask, why bother?
It might save some space in the long term, but in my worldview, for as long as something still fits on a floppy disk [for want of something that's empirically "so small it doesn't even register in my consciousness"], who cares! I'd have to try it, but I'll bet that even a whole cross-country road trip in kml would fit on a floppy if you gzip it.
If you posted code that draws another ten layers, I'd probably just throw it in there without a second thought.
Assuming you really do want to do it, I think there's a couple things worth thinking about.
1) Single letters suck. It doesn't take long to run out of them in total, and it sure as hell doesn't take long for them to completely devolve from what they actually stand for. What do you do for ten graphs plotting speed vs something else? The letter "s" only gets to be used once. Letter pairs doesn't get you a lot further.
2) Perhaps there's a magical "correct" solution lurking here:
Change the code so that rather than being a bunch of hand-coded layers plotted, have them fully configurable.
Code:
/// What type of layer to draw
enum obdlayertype {
LAYERTYPE_HEIGHT_AND_COLOR, //< Graph of height and color
LAYERTYPE_SINGLE_HEIGHT, //< Graph of just height
LAYERTYPE_WIDE_LINE //< Graph of a line following the road, changing width [not yet implemented]
};
/// This is a linked list containing all the layers we're going to plot
struct layer_list {
obdlayertype layertype; //< The type of layer this represents
const char *firstaxis; //< The first axis that will be plotted
const char *secondaxis; //< The second axis that will be plotted [not relevant for all graphs]
const char *kmlname; //< The "name" as it will appear in google earth
const char *kmldesc; //< The "description" as it will appear in google earth
int normalisedheight; //< The height to normalise this graph to
struct layer_list *next; //< Woo, linked lists.
};
This is obviously a first start just off the top of my head, and I can already see it's not great.
But the path I'm working towards here is having a default set of graphs that obd2kml would draw, but if someone explicitly requests some graphs we can draw those instead. eg:
Code:
obd2kml --layer="obd.vss" \
--layer="(710.7*obd.vss/obd.maf)"
Would draw two graphs, one of speed and one of mpg. If no --layer options were passed, then it would populate the linked list itself from a sensible set of defaults.
To make this work well, it's already spiralled outside of simplicity, but it gives an idea for real future expansion; properly let people configure what graphs they want.
I think this whole thing probably warrants a lot more thought than I have time to put into it today. Feel free to implement something like you described, but I get the feeling that it won't be good for a long-term solution.
Gary (-;
PS I still get the "why bother" vibe overall. I suspect that until you've actually *shown* any kind of real problem with dumping the whole lot, it's probably not worth caring about.
Linear Mode
