Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

standardized data input #2080

Open
ConstantinoSchillebeeckx opened this issue Jul 26, 2017 · 4 comments
Open

standardized data input #2080

ConstantinoSchillebeeckx opened this issue Jul 26, 2017 · 4 comments

Comments

@ConstantinoSchillebeeckx
Copy link
Contributor

Would it make sense to think about standardizing the format for data input, perhaps one that is more in line with columnar data?

Currently, input formats seem to vary across the various charts. For example, the scatterChart does not have explicit accessors for x or y, instead you attach the data with datum() in a format like

[
  {
    x: ...,
    y: ...,
    shape: ...,
    size: ...
  },
  ...
]

On the other hand, cumulativeLineChart does have explicit accessors for x and y which access the values property of the attached data, formatted as

[
  {
    key: "some label",
    values: [ [x-value,y-value], ... ],
    mean: 250
  },
  ...
]

Similarly, discreteBarChart also has accessors for x and y, but expects a different data format:

[
  {
    key: "Cumulative Return",
    values: [
      {
      "label" : "A" ,
      "value" : 29.765957771107
      },
      ...
    ]
  },
  ...
]

The charts on a whole might be more flexible if the expected data format is standardized, and if each plot always has (at least) an x and y accessor.

A proposed data format might be in the form of

[
  {
    attribute-A: value-A,
    attribute-B: value-B,
    attribute-C: value-C,
    ...
  },
  ...
]

This is a more natural fit to data originating from, say, a CSV. The x and y accessors could then directly access any of the attributes of the data. Labels or keys could simply be taken from the attribute name.

If there's interest, I'm willing to help convert charts over. 🍻

@bgth
Copy link
Contributor

bgth commented Sep 9, 2017

hi @ConstantinoSchillebeeckx. Is it possible to help in contribution to migration to d3js v4? We can discuss about this change as well during the migration and include. d3js has long moved away from v3 and if nvd3 moves to v4 as well it will be really great.

there is a PR which is actually looking at migration to v4 now. #2082

@liquidpele
Copy link
Contributor

In addition to this, I'd really like to move to using key functions...

https://bost.ocks.org/mike/constancy/#key-functions

Making people have to meticulously keep their data structure the same when changing values has been a constant stream of questions/bugs...

@ConstantinoSchillebeeckx
Copy link
Contributor Author

ConstantinoSchillebeeckx commented Sep 9, 2017

Couldn't we just manually add in an index key as a standard data ingest practice? Looks like you're already doing it in a few charts.

@bgth - I just noticed @liquidpele created a branch for v4, I'd be down for helping; any thoughts on where to begin or how to organize ourselves?

@liquidpele
Copy link
Contributor

No, that's basically just so the series index gets passed to the tooltip/eventHandlers. Using the key functions is the "right" way and even allows for transitions/etc in data updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants