显式指定 data 类型

[pearmini]

channel.dataType

Vega-Lite: https://vega.github.io/vega-lite/docs/type.html

希望给 G2 支持如下的写法：

G2.render({
  type: 'interval',
  data: [
    { genre: 'Sports', sold: 275 },
    { genre: 'Strategy', sold: 115 },
    { genre: 'Action', sold: 120 },
    { genre: 'Shooter', sold: 350 },
    { genre: 'Other', sold: 150 },
  ],
  encode: {
    x: { dataType: 'categorical', value: 'genre' }, // 显式声明为离散的数据
    y: { dataType: 'quantitative', value: 'sold' }, //  显式声明为连续的数据
  },
});

支持的 dataType 类型如下：

• ordinal - 可排序离散数据，比如 ['a' , 'b', 'c']
• categorical - 不可排序的离散数据，比如 ['red', 'blue', yellow']
• quantitative - 连续数据，比如 [1, 2, 3]
• temporal - 时序数据，可以是 Date 或者可以转换成 Date 对象的 Date String

大部分用户应该感知不到这个特性，所以不会增加他们的学习成本。

存在问题

目前 data 的类型会在创建 Scale 的进行推断，并且反应在对应的比例尺上，比如 ordinal 数据的使用 ordinal 比例尺。但是这样会存在一些问题：

• 不符合传统的思考方式：比例尺的类型是通过数据类型决定，但是支持设置比例尺类型。如果用户是知道数据类型，还需要自己维护一套数据类型到比例尺类型的映射。这对智能可视化的推荐很不优化，这类推断是直接推断出的数据类型。
• 数据类型多次声明：数据类型不仅仅在生成比例尺的时候用到。比如 sortX transform 针对离散和连续数据的排序方法是不同的，所以就必须显式的声明 isOrdinal 配置。但是后面又会推断一次，如果推断的不一样会略显奇怪。
• 对于时序数据支持不好：没有办法支持内置的 Date String 的解析。

Ordinal

const options = {
  type: 'interval',
  data: [
    { a: 'B', b: 55 },
    { a: 'A', b: 28 },
    { a: 'C', b: 43 },
  ],
  encode: {
    x: { dataType: 'ordinal', value: 'a' }, // 会按照字母序排序
    y: 'b',
  },
};

Categorical

const options = {
  type: 'interval',
  data: [
    { a: 'B', b: 55 },
    { a: 'A', b: 28 },
    { a: 'C', b: 43 },
  ],
  encode: {
    x: { dataType: 'ordinal', value: 'a' }, // 不会按照字母序排序
    y: 'b',
  },
};

Temporal

const options = {
  type: 'interval',
  data,
  encode: {
    x: { dataType: 'temporal', value: 'hour', format: 'YYYY-MM-DD HH' }, // 指定解析方法
    y: 'b',
  },
};

SortX

// Before
export function gammaRandomLineSortXQuantitative(): G2Spec {
  return {
    type: 'line',
    data: {
      type: 'fetch',
      value: 'data/gamma-random.json',
    },
    encode: {
      x: (d) => d,
      color: 'steelblue',
      shape: 'smooth',
    },
    transform: [
      { type: 'binX', y: 'count' },
      { type: 'sortX', ordinal: false },
    ],
    style: {
      lineWidth: 2,
    },
  };
}

//  After
export function gammaRandomLineSortXQuantitative(): G2Spec {
  return {
    type: 'line',
    data: {
      type: 'fetch',
      value: 'data/gamma-random.json',
    },
    encode: {
      x: { value: (d) => d, dataType: 'quantitative' }, // 指定数据类型
      color: 'steelblue',
      shape: 'smooth',
    },
    transform: [{ type: 'binX', y: 'count' }, { type: 'sortX' }],
    style: {
      lineWidth: 2,
    },
  };
}

[Aarebecca]

几个地方有点小错误：

• 显示 ➡️ 显式
• Categorical 示例代码中 dataType 应该是 category 吧

另外有个问题是，如果用户手动指定的数据类型是错误的，会咋样呢。
Scale 是否可以推断出可选的数据类型，即是是用户手动指定的也需要在可选类型当中

[pearmini]

• 应该就是 categorical ？因 category 是个名次，但是其他 temporal 这些都是形容词。
• 用户指定了数据类型之后，scale 就不用去推断了（尽管用户指定的是错的），数据类型的优先级别是最高的。

[neoddish]

用户指定错误，是让用户直接编辑 spec 时不可避免会发生的问题，不局限于数据类型的设置。

vizLinter 一类的工作、JSON Schema 一类的附属工具，正是为了帮助解决这一类问题。但是，并不需要完全解决。

[pddpd]

@ixuxinyue 需要考虑 dataType 和 AVA LOM 的兼容性

https://github.com/antvis/AVA/blob/v3/packages/ava/src/ckb/constants.ts#L167

附参考
Level of measurement Wiki

[neoddish]

Nominal 和 Category 应该是同义的

也有一种理解是：Categorical（分类的）可以分为 Nominal（名词分类的、无序分类的）和 Ordinal（有序分类的）两种子类型。

@pearmini 同时可以考虑，这两种类型是可以转化的。只要有一个 compare 方法，Nominal 的数据都可以转化为 Ordinal。

[neoddish]

AVA 的分类也是结构层级上不完全严谨的，也是一种妥协。比如：

• 语义概念的不严谨
  • Ordinal 只代表有序，不一定局限于有序名词。讲道理 discrete、continuous、time 都是“有序的”
  • 部分概念存在交集，并不 MECE
• 层级结构的不严谨
  • Categorical 可以分为 Nominal 和 Ordinal，可以和 interval/numerical 平级的。但 interval 出现在里面，categorical 却没有
  • 如上，这个 LOM 本质上可以是层级结构，却拍平成了一个数组

实际上，要完全严谨的定义上面的概念是很难的。特别是用在工程里，比如硬要写成一个层级结构的对象，这样严谨是严谨了，但在使用时是很麻烦的、没有必要的。

所以可以讨论如何尽可能严谨和 MECE 的情况下做合理的妥协，符合 AVA、G2 和主流可视化工具和用户的需要。

参考：
https://www.yuque.com/neowang/zjvis/zrunlr

[neoddish]

还有一种考虑方案：将概念按需求明细程度分层。

比如，假设 G2 在绘制层面，只需要考虑 categorical 和 quantitative（本质上只需要区分 string、number）就可以了。而 AVA 图表推荐时要知道更多，比如 number 是 discrete 还是 continuous（本质上是int 还是 float），那么可以 spec 层面不体现，只在 AVA 内部的推荐过程汇中针对 number 做 isDiscrete 或 isContinuous 的判断，决策后就不需要了，输出时也不体现。

[pearmini]

嗯嗯，G2 层面比较理想的是分为：categorical，quantitative 和 temporal，这样可以降低小白用户的使用成本。然后 AVA 可以进一步分层。

[neoddish]

嗯嗯，G2 层面比较理想的是分为：categorical，quantitative 和 temporal，这样可以降低小白用户的使用成本。然后 AVA 可以进一步分层。

可以

[hustcc]

要考虑两个点的平衡：

1. 专业性带来的成本和门槛，数据类型带来了 90% 以上的前端开发不理解，这也是为啥 scale 是 G2 最难的概念（比 coordinate 还难）
2. 一个新设计解决的问题有几个层次：能力阻断、使用优雅、设计优雅。如果 dataType 解决的不是 阻断 的问题，先解决阻断的问题。

这个点建议暂时 hold，先做 3.21 相关紧急重要内容：bugfix、组件自定义、能力覆盖、文档/DEMO。

[pearmini]

嗯嗯，这个优先级没有很高，也有暂时的替代方案。

[pearmini]

如果这里觉得 dataType 这个配置比较丑的话（大部分人都可能认为），可以改成 measure，因为 vega-lite 的 type 其实也是基于这个来的。

使用方式就如下了：

G2.render({
  type: 'interval',
  data: [
    { genre: 'Sports', sold: 275 },
    { genre: 'Strategy', sold: 115 },
    { genre: 'Action', sold: 120 },
    { genre: 'Shooter', sold: 350 },
    { genre: 'Other', sold: 150 },
  ],
  encode: {
    x: { measure: 'categorical', value: 'genre' }, // 显式声明为离散的数据
    y: { measure: 'quantitative', value: 'sold' }, //  显式声明为连续的数据
  },
});

[ixuxinyue]

我感觉这种方式合理些
另：measure是度量的意思，这边应该起个度量尺度的名儿，这个命名可以再讨论下子

[neoddish]

确实，level of measurement 和 measure 是两回事。。。

[visiky]

measure 这个命名不太合适吧。另外，我同意逍为的看法，scale type 已经很复杂了，现在又来了 encode data type，很多叉乘之后，就更复杂了。

[pearmini]

这里不能作为 data def 的原因是：同一个字段可能帮绑定多个通道，而这些通道的类型是不同的，比如如下的例子中：sold 字段既和连续的 x 通道绑定，又和离散的颜色通道绑定。

[neoddish]

所以类似于 categorical 这类的值，在 G2 里到底是有哪些”消费“的地方？

比如，他是和 scale 完全绑定的么？只影响 scale？

[neoddish]

确实放在 encode 是有好处的。放在 dataDef 层级其实可能不知道哪里具体消费。放到 encode 或 scale 起码很明确是个消费口径，我在这里一改，意思就变了，显示逻辑也变了。

如果从 dataDef 里写，我认为好处是在”元数据“级别指定了数据的”默认类型“。那么比如 encode、scale 或者别的什么地方都要用到的话，如果不特殊指定，默认就是那个类型。否则，每个要用的地方都要指定一次类型。

可以考虑下这个区别，以及到底哪些地方会消费这个类型指定。

[pearmini]

嗯嗯，主要是影响 scale，还会影响 sortX 这个 transform（不过这个不是很重要）。

[pearmini]

多个地方都可以指定也是一种思路，但是我觉得没有必要。

[ixuxinyue]

补充在这个例子下面，如果采用field type 写入scale 的方案，要完成如图这样的图表，让 y 对应数据为数值通道，color为离散，此时要对 y 进行比如说取 log 的处理，那 y 对应的 scale 该怎么表达呢 这里面也涉及到叉乘的

[hustcc]

@neoddish @ixuxinyue 应该是不阻断，用 scale.type 就能解决吧。

function getScaleType(type) {
  if (type === 'categorical') return 'ordinal';
  if (type === 'quantitative') return 'linear';
  if (type === 'temporal') return 'time';
}

当前在 encode 中增加 type 会导致 encode api 负责度高很多，倒是可以在 data.fieldDef 中设置，但是如果不阻断的话，也可以暂时不加。

[neoddish]

@ixuxinyue 请给出阻断的案例和说明。

然后给出你作为用户和对接方的需求视角的建议，期望用哪种方式。

[ixuxinyue]

在 AVA 中的 chart linter 部分 有一部分规则需要根据字段的type来进行修复方法的推荐，例如

还有根据spec中的数据类型推荐色板

如果我是用户，我理解会使用 g2-spec 的用户一般都是有一定可视化知识的，我希望能跟vega的用法保持一致，对我会更友好些。
另外 scale 我认为是一种转换的操作，从原始的操作转换为指定的类型，同时 scale type 很复杂，在手写 g2 spec 的场景下，那如果需要用户手动通过scale去指定对应channel的type，对用户来说是否学习成本过高尼

[neoddish]

以及，encode.type 和 encode.scale.type 是两回事。encode.type 用来说明字段在被映射时所指定的数据类型。比如，数值映射到颜色，type:'categorical' 说明是离散色板，type: 'quantitative' 说明是连续色板。而 scale.type 是用来指定在做数值转换时使用的转换类型，比如：在之前我已经指定了数值要映射到”连续色板“，从数据转化到连续色板时可以做'pow','sqrt','log'等变换。

VL 的这个文档很好的说明了这个问题：https://vega.github.io/vega-lite/docs/scale.html#type
其中有两张表，第一张讲的是所有 scale 的类型。第二张讲的是在不同encode.type和 channel组合下的默认 scale 类型选择。除了默认scale 类型，当然还要允许spec指定 scale类型，这就是为什么要分 encode.type 和 scale.type

参考这个关于”为什么不把nominal/ordinal合并成 categorical"(虽然这是另一个话题)的讨论，看 heer 和其他作者的观点，也能看到这种分类在实际应用中的具体作用
vega/vega-lite#6633

[neoddish]

所以我的观点是：

• encode.type 不等于 scale.type，这两个都是要有的
• encode.type 是 AVA 必须的，因为上一点，不能用 scale.type 来代替
• 至于放在 data. 下面， 还是放在 encode. 下面，这两个方案各有利弊（https://github.com/antvis/G2/discussions/4659#discussioncomment-5060540），选一个就行

[neoddish]

VL 的这个文档很好的说明了这个问题：https://vega.github.io/vega-lite/docs/scale.html#type 其中有两张表，第一张讲的是所有 scale 的类型。第二张讲的是在不同encode.type和 channel组合下的默认 scale 类型选择。除了默认scale 类型，当然还要允许spec指定 scale类型，这就是为什么要分 encode.type 和 scale.type

这个第二张表格，其实就很能说明问题。如果采用上面提到的 根据 scale.type 和 encode.type 的关系来推断，想通过这种方式来节省一个概念，就算能做到（还没考虑 channel 这个维度）实际上也只是在能力上只提供的表二中的 default 能力。所有其他（叉乘带来的）可能性的能力就都不能描述了。

[pearmini]

type Primitive = number | string | boolean | Date;

type TabularData = Record<string, Primitive>[];

type Callback = (
  datum: Record<string, Primitive>,
  index: number,
  data: TabularData,
) => Primitive;

type Encode = Primitive | Callback;

type ScaleType =
  | 'linear'
  | 'log'
  | 'pow'
  | 'sqrt'
  | 'qunatile'
  | 'threshold'
  | 'quantize'
  | 'sequential'
  | 'time'
  | 'point'
  | 'band'
  | 'ordinal';

type DataType = 'quantitative' | 'categorical' | 'temporal';

function isQuantitative(d: any): boolean {
  return typeof d === 'number';
}

function isCategorical(d: any): boolean {
  return typeof d === 'string' || typeof d === 'boolean';
}

function isTemporal(d: any): boolean {
  return d instanceof Date;
}

function isField(data: TabularData, encode: Encode): encode is string {
  return (
    typeof encode === 'string' && data.some((d) => d[encode] !== undefined)
  );
}

function isTransform(data: TabularData, encode: Encode): encode is Callback {
  return typeof encode === 'function';
}

function scaleType2dataType(scaleType: ScaleType): DataType {
  switch (scaleType) {
    case 'linear':
    case 'log':
    case 'pow':
    case 'sqrt':
    case 'qunatile':
    case 'threshold':
    case 'quantize':
    case 'sequential':
      return 'quantitative';
    case 'time':
      return 'temporal';
    case 'ordinal':
    case 'point':
    case 'band':
      return 'categorical';
  }
}

function values2dataType(values: Primitive[]): DataType {
  if (values.some(isQuantitative)) return 'quantitative';
  if (values.some(isCategorical)) return 'categorical';
  if (values.some(isTemporal)) return 'temporal';
  throw new Error(`Unknown type: ${typeof values[0]}`);
}

function columnOf(data: TabularData, encode: Encode): Primitive[] {
  if (isTransform(data, encode)) return data.map(encode);
  if (isField(data, encode)) return data.map((d) => d[encode]);
  return data.map((d) => encode);
}

function inferDataType(
  encode: Encode,
  scale: ScaleType,
  data: TabularData,
): DataType {
  if (scale !== undefined) return scaleType2dataType(scale);
  const values = columnOf(data, encode);
  return values2dataType(values);
}