Describing data loaded into SandDance Explorer
See original GitHub issueCurrently we are loading data through the mounted
callback, calling load
on the Explorer
component and passing an array of objects.
It’s clear that SandDance has some default logic for how to describe data; string values are categorical, numbers are quantifiable, etc. Additionally, I imagine that SandDance does things like encoding the string values into numbers in order to speed operations.
However, in loading the data ourselves, we probably have (or can store/extend) metadata about our data to assist SandDance in this (as well as correct any false assumptions).
As an example, if we have rows of data, like so:
{
id: 1,
description: 'some thing',
otherId: 4,
category: 'car'
}
In this case, we know the following:
id
is unique, it’s self categorizingdescription
is unique (let’s assume) and a numeric representation is already encoded inid
otherId
is categorical, not quantitative, and we shouldn’t allow aggregates on itcategory
is categorical, and needs an encoding for it
That said, I see that there is a Column
type in the TypeScript declarations which has some of that data (as well as min/max values, etc.). I also see that there is a DataContent
interface which has the data and Column
types exposed, and this looks promising.
The question is, are there options for us to actually help SandDance explorer with this decision, or are these default assumptions the only choice we have?
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:8 (4 by maintainers)
Top GitHub Comments
Actually the callback can optionally return an
Insight
object, which tells it how to render a chart. For an example of this object, you can callexplorer.viewer.getInsight()
to see the params of the current chart view.@danmarshall Apologies, I did see that; we may try that; we have it working for now, setting the values on the
Insight
, so no need to trim it. I see the fix of the TS definitions as nice-to-have and not a blocker.We may use that call for other things, however, so thank you for showing there is more than one way to approach the issue.