Skip to content
 

A compelling reason to go to London, Ontario??

Dan Goldstein asks what I think of this:

My reply:

It’s hard for me to imagine a compelling reason for anyone to go to London, Ontario–but, hey, I guess there’s all kinds of people in this world! More seriously, I see the appeal of the graph but it’s a bit busy for my taste. Over the years I’ve moved toward small multiples rather than single busy graphs. That’s one reason why I prefer Tufte’s second book to his first book. The Napoleon-in-Russia graph is a bad model, in that inspires people to try to cram lots of variables on a single graph.

Dan wrote back:

I [Dan] like it as a travel planning graph, it gives you what you want to know (how how will the days be, how cold will the nights be, will it rain) but is a bit easier on the brain than a table of highs and lows. Also makes it easy to see the trend.

I agree the 2nd axis doesn’t help.

13 Comments

  1. Joseph says:

    When I lived there the used bookstore was the best reason to stick around. I am not sure if it still exists, but it was epic at the time.

  2. Rahul says:

    I suspect a lot of traditional Tufteisque heuristics will need tweaking as we move from the printed page to more interactive media. It isn’t so bad to cram a lot of info. on a graph when there’s a option of hiding series’, zooming in etc.

    e.g. For a data-crowded scatter plot labeling points used to be a nightmare; mouse tooltip popups have made this more manageable. Incidently, a question for the experts: Of all the plotting routines (Gnuplot, Matlab, Excel) I’ve used I’ve never found a scatter plot procedure that can avoid label overlap intelligently. Are there any programs that are good at this?

    I cringe to think of the global time wasted in manually moving datapoint labels around on scatter plots.

    • John Mashey says:

      Tufte’s admonition about using less ink certainly applies, but indeed, interactive graphics change the rules.

      Nick Stokes has some interesting graphs at Moyhu. See especially this one, which uses a mouseover of labels to highlight each of the lines in the “spaghetti graph.”
      This really helps.

  3. K? O'Rourke says:

    Or perhaps Toronto, Ontario?

    To hear Xiao-Li Meng talk on wine (and statistics).

    http://www.utoronto.ca/reg/list_full.pl?20120019-1530.30799

    p.s. and if you are only 19 you can legally taste the wine there

  4. John says:

    This seems like the not-as-good version of weatherspark.com.

  5. misterarthur says:

    Re: Visiting London, Ontario. If you enjoy highway wreckage, it might be worth a stop.
    From wikipedia ” Due to fatigue caused by the lack of driver engagement along the flat and straight lengths of highway,[19] the section of Highway 401 from Windsor to London (especially west of Tilbury) has become known for deadly car accidents and pile-ups, earning it the nickname Carnage Alley.[20] As the highway approaches London, Highway 402 merges in,[14] resulting in a six lane cross-section.[21][22] Within London, it intersects the city’s two municipal expressways, Highbury Avenue and the Veterans Memorial Parkway.[23]“

    • theDAWG says:

      You beat me to it. I was going to use New London, CT because haha.

      It’s a small multiples version that keeps units constant for each individual graph. Once you switch to different units on the same graph, comprehension quickly goes way down.

  6. Ted Dunning says:

    The real problem with this system is that it doesn’t have much coverage. Pretty plot are nice, but data to plot is the pre-requisite.

    I just tried the towns along I-5 in CA. They had LA. Not Grapevine, not Buttonwillow, not Kettleman City, not Gilroy. That makes it pretty hard to use for any kind of trip planning.

  7. Peter Flom says:

    One problem is the day/night lines. I’m not sure they are needed, but, if they are, they should be accurate. In January, day and night are not equal lengths of time. For example, Jan 9 will have 9 hrs 8 min of daytime and 14 hrs 52 min of night.

  8. jrkrideau says:

    @Peter Flom,

    It looks like the days and nights are reversed, in fact. I would suspect a production error and someone mistakenly picked June or July for the day-night coding function rather January.

    It is a bit to busy a graph for my taste but I probably beats tables.

    As to Andrew’s comment about why would anyone want to go there: The weather, of course, Hot and humid in the summer; cold and damp in the winter, interspersed with exciting winter blizzards.

  9. MDJ says:

    @Peter Flom,

    x-axis indicates time of year is April, which would be close to equal days and nights.