Refactor Dimensions to an array of objects

[syntagmatic]

This would provide a nice way to configure dimension properties ahead of time without fiddling as much internally with lookups or matching indices. For instance, adding an axis property would be straightforward here.

All the autoscale functionality can be factored out to generate this data structure, cleanly separating that from the rest of the library.

http://bl.ocks.org/mbostock/3709000

var dimensions = [
  {
    name: "name",
    scale: d3.scale.ordinal().rangePoints([0, height]),
    type: String
  },
  {
    name: "Acc. 40º 150%",
    scale: d3.scale.linear().range([0, height]),
    type: Number
  },
  {
    name: "Scale",
    scale: d3.scale.linear().range([height, 0]),
    type: Number
  },
  {
    name: "Areal",
    scale: d3.scale.sqrt().range([height, 0]),
    type: Number
  },
  {
    name: "Angular",
    scale: d3.scale.linear().range([height, 0]),
    type: Number
  }
];

[bbroeksema]

I guess this is meant to replace the current dimensions function. I'm all in favor of this as I'm currently keeping track of axis semantics in my application. This approach would nicely fit in.

[lkapsokalyvas]

That would be very useful in cases where string values in an axis need to be sorted alphabetically. Currently, it seems that there is no way of doing this with the default scales. In fact calling autoscale repeatedly will cause the order of values in a string axis to change.

[syntagmatic]

Work in progress on this issue. http://bl.ocks.org/syntagmatic/8ff691209324f1814257

[julianheinrich]

@syntagmatic I've come across the problem of having to duplicate axes. This can be desirable in some cases, but currently requires to copy all items of a dimension and to give it a different key. I was wondering if this could be avoided with your new approach? For example, would it be possible to add a dimension with a different key pointing to some other dimension instead of copying the data?

[syntagmatic]

More examples:

http://bl.ocks.org/syntagmatic/0d1635533f6fb5ac4da3
http://bl.ocks.org/syntagmatic/94be812f8b410ae29ee2
http://bl.ocks.org/syntagmatic/4446b31c6cd746eedaeb

Duplicate dimensions don't magically work with this approach, because the xscale still uses the dimension key for its domain. If xscale instead used the dimension index, that would work.

[syntagmatic]

Also it's worth checking out Vega's approach to this:

http://vega.github.io/vega-editor/index.html?spec=parallel_coords

[syntagmatic]

@julianheinrich Using an xscale domain with dimension index instead of dimension key does enable duplicate dimensions! It also saves a few characters in the code, avoids some object lookups when rendering, and feels more correct.

I updated the pattern here:

http://bl.ocks.org/syntagmatic/0d1635533f6fb5ac4da3

Try forking the gist and duplicating any of the objects in the dimensions array. Energy, Protein and Total Lipid Fat duplicated:

[julianheinrich]

@syntagmatic awesome!
do you have time to refactor the code soon to reflect this approach?

[syntagmatic]

@julianheinrich I'm not planning to work on a major refactor or this library in the next month or so. It's more convenient to experiment with structural/fundamental changes to the pattern with straight D3.js.

If someone wants to take on the challenge of refactoring the library, I'd be happy to comment/participate though!

[syntagmatic]

Check out http://bl.ocks.org/syntagmatic/0d1635533f6fb5ac4da3 for the latest prototype reference for this feature.

For including in d3.parcoords, this pull request by @mcwillso is the cutting edge. #265