Modify color scale and classification

[do-me]

When coloring by a variable, the color scale and classification are hard-coded.

I think in descending priority it would be good to add:

1. Color scale inversion (as a high price can be positive or negative)
2. Class number (how many classes you want)
3. Custom colors for each class
4. Custom class breaks and/or automatic ones (Jenks etc.)

For inspiration: QGIS has the most complete class and color editor I know of. Reproducing the full editor on the web might be overkill of course, but I think it's worth a look.

[do-me]

I did some experimenting locally for geospatial atlas. Would something like this suit your needs too?

[donghaoren]

This looks great! Thanks for investigating on this. We'd appreciate a pull request.

[do-me]

Cool, first I'll give it a little more thought though. Do you have any (internal) roadmap or any opinions at all on how much styling you want to allow or what would be too much or worse overload the user?

I can think of so many use cases - forgive my GIS perspective, but also relevant for embeddings - where more styling options would be very helpful, just to name a few:

• different symbols (ideally for displaying different features/classes)
• an option to toggle off your custom aggregation style (where highly dense areas get a slightly different color shade)
• point outlines to differentiate large clusters better (but then you'd also like to set the outline width, color etc.)
• and many more...

I'd like to avoid creating a PR that would cause breaking changes in the near future.

[domoritz]

Love it. In terms of terminology, let's make sure we are consistent with embedding atlas internals or https://vega.github.io/vega/docs/schemes/. Not saying these are right but maybe consider:

• classes -> count or steps
• invert -> reverse
• method -> bin width (and what are good terms for the methods here "equal-width", "equal-height" or "equal-width", "quantiles").

In terms of features, I'd say let's keep the UI lean and focused but we could expose more options in the spec which can be set by a developer. We don't have plans for supporting a ton of configuration but ideally come up with good defaults. Our goal is not not make a tool that allows you to build a chart that exactly looks like you want it to but to provide a tool that lets you effectively look at data. If there is a feature that makes exploration more effective or allows for new insights, that's great. If the feature is almost exclusively aesthetic, we probably will be hesitant. But that's just a guideline, not a strict rule.