Per-column CSV table styling

[stevage]

Something in the back of my mind for a while. Our init file format only lets you specify one style, which applies to one column. So when the user selects a different column in the interface, Terria is flying blind.

We should perhaps have something like:

tableStyle: {
  columns: {
    lga: {
      regionType: "LGA_NAME",
    }
    pop: {
      colorMap: "black-red",
      title: "Population"
    }
    migration: {
      colorMap: "red-black-blue",
      title: "Net migration",
      colorBinMethod: "quantile"
    }
    type: {
      colorMap: "Set3",
      title: "LGA type",
      varType: "ENUM"
    }
  },
  dataVariable: "pop"
}

[axman6]

This looks great to me, I'm sure we'll find many uses for this.

[stevage]

Just a thought. If the column identifier can be a regex, then it would integrate well with #1111.

I guess we should have have explicit regex markers ("/_population$/": ...). If we tried to treat everything as a regex, it would give very surprising behaviour when someone tried to specify a column name like "diameter (metres)"

[RacingTadpole]

Thinking some more about this. Here is the current (mid Feb 2016) list of Table Style attributes. The first set are global, so would not be available in tableStyle.columns:

• regionVariable
• dataVariable
• featureInfoFields
• timeColumn

But as you say the remainder really should be column-specific:

• regionType
• minDisplayValue
• maxDisplayValue
• displayDuration
• replaceWithZeroValues
• replaceWithNullValues
• nullColor
• nullLabel
• scale
• scaleByValue
• clampDisplayValue
• imageUrl
• colorBins
• colorBinMethod
• colorMap
• colorPalette
• legendTicks

The current behaviour is to apply these to all columns, so I'd also suggest that eg.:

"tableStyle": {
  "colorMap": "red-orange",
  "legendTicks": 8,
  "columns": {
    "pop": {
      "colorMap": "black-green"
    }
  }
}

would apply the 'black-green' color map to the 'pop' column and 'red-orange' to all the other columns. All columns would have 'legendTicks: 8', ie. defaults set at the top level flow through to each column.

Adding a title and a type per column is a great idea too. We could also add a format parameter down the track, eg. whether to format numbers with a thousands separator, or to format dates.

And one last extension - I'd suggest also letting the column keys be numbers, to reference a particular column by its position (probably zero-based). It could foster bad practice, but I can also imagine cases where the column title is less stable than its position.

[stevage]

How about a description per column, too? That could be shown as hover text in the legend and feature info boxes?

Not sure about the column keys as numbers - doesn't sound too harmful, but what's the use case?

[RacingTadpole]

Cool - can you raise description in a separate issue?
I'll run with column numbers as an option, since I've already implemented it. I don't have a specific example, but I can imagine that if a csv file is manually updated, its column names might change slightly (eg changing underscores to spaces, or changing capitalisation, or adding units in brackets). If you think that's a possibility, you might prefer to reference the column by its position.

[zdefne-usgs]

@RacingTadpole and @stevage
Would the same approach work with "units" too? For example, I have a table with many columns with units of change in length, but one of the columns displays change in mass. Doesn't seem to work. Is it because I cannot define units under "tableStyle" out side the scope of "columns"? Thanks!

            "tableStyle": {
                "units": "mm/yr",
                "scaleByValue": true,
                "columns": {
                    "mchange": {
                        "name": "Change in mass",
                        "units": "tonnes/yr"
                     }
                }
            }