Thread: New Release 0.5

On the general topic of the software, I am now fairly familiar with the code and the coding style. You have a nice and straightforward way of structuring your code, I find it easy to follow.

I will be posting my KML files on a personal road trip website. I have been considering some enhancements to the output options for obd2kml. What do you think of these?

I would like to tell that utility to generate graphs only for trips within certain dates. That will allow me to be building up a big overall trip graph, while also being able to provide snippets of my trip from my last blog post. I suggest something like

Code:

obd2kml --from 2009-06-01 --to 2009-06-04

Similarly, I would like to tell that utility which layers to generate. I plan on writing some new layers to explore and experiment with what kinds of graphs are possible. I propose that the layers get named by a letter, and that we pass those letters on the command line, something like

Code:

obdgpslogger -L abceghm

The second suggestion is something I can achieve by commenting some code and recompiling, so it is a lower priority. I plan on working on that first suggestion myself, and I only mention it here because last time you jumped on my suggestions eagerly and had them done before I could even think about them. Depending on the amount of time you spend developing obdgpslogger, I have plenty of suggestions.

Huh, interesting ideas. I'll address them in separate posts.

Given that trips are started and stopped by starting and stopping the engine, and the database is kinda keyed from the point of view of trips, it seems like it would be more useful to allow someone to dump specific trips to kml [rather than selecting datums based purely on date]. If you're envisaging selecting trips based on those two date parameters, then feel free to ignore what I'm about to say.

I can think of a couple things that might work:
1) Give a trip list and then let people choose them:

Code:

$ obd2kml --list-trips
TripID       Start                       End
1          2009-05-06 21:03     2009-05-09 06:12
2          2009-06-01 09:33     2009-06-01 10:45
$ obd2kml --trips=1-2

By just doing ranges, you make it easy to sscanf, and the sql WHERE clause is easier to build. [go me, lazy as hell as ever]

The other benefits of this is that you don't have to deal with time conversions [except once, for printing to stdout - which is a lot easier than trying to parse stuff and convert to epoch seconds], and that you don't have to worry about timezones.

2) Another option might be to do what you describe, but use the dates to select the trips. You could modify the trip select sql [around line 157 in obdgpskml.c] to be something like:

Code:

char select_trip_sql[4096];
snprintf(select_trip_sql, sizeof(select_trip_sql),
   "SELECT tripid,start,end FROM trip
         WHERE (trip.end<%f AND trip.end>%f)
         OR (trip.start<%f AND trip.start>%f)
         ORDER BY tripid", endtime, starttime, endtime, starttime)

And you'd get all trips that touch the timeframe you've described.

Again, you'd have to parse the dates as input to convert them to epoch seconds. Which sucks to do portably IME, which is why you'll notice my code never attempts to do such a thing.


I'm not sure which of these would be "better" - this is probably one of those times where we can either talk about it, or you can just post a patch and I'll probably accept it. Or you could wait a couple days while my brain percolates the issue and I figure out how I think it would be best done, and I get round to implementing it.

Gary (-;

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.

Oh, and in case it isn't obvious, I like to spend a lot of time thinking about how code will work before actually writing it :-)

Gary (-;