Roadmap Ideas

[jonmmease]

Something that I think would be helpful for the Altair community is for the maintainers to document their plans for the project in the form of a roadmap. I wanted to start this thread as a place to drop ideas for the roadmap. I think it would be great if we could get at least an initial draft of a roadmap done in time for the Vega conference in September. This way we could include it as part of the project update to the rest of the Vega community.

There are four big areas that I've heard folks talk about that I thought we could use as a starting point:

1. Scale/performance improvements
2. Geo improvements
3. Gridded data support
4. Expand coverage of possible statistical chart types

Scale/performance improvements

This is the area that I'm most focused on, and the roadmap here is somewhat linked to the VegaFusion roadmap.

• VegaFusion data transformer to move data transformations out of the browser (will be coming in version 5.1)
• Support pushing transforms to external databases / compute engines through integration with SQL systems, Ibis, Dask, etc.
• Binary serialization of large unaggregated datasets in conjunction with the Jupyter widget
• Support dynamically re-aggregating / re-filtering data on the server in response to interactions with the built-in Jupyter widget (i.e. port the VegaFusionWidget functionality to the Altair widget)
• Automatic timeseries downsampling with m4
• Streamline construction of interactive charts that deal with large datasets (e.g. zoom based heatmap binning, zoom-based m4 downsampling)
• Support pre-rendering large marks on the server with VegaFusion
• Support GPU accelerated rendering on the client (along the lines of https://github.com/vega/vega-webgpu).

Geo improvements

• Complete and integrate altair_tiles

What else @binste @mattijn?

Gridded data support

• First class support for x-array datasets (rendering large gridded datasets may depend on some of the performance work)

What else @mattijn? @joelostblom?

Expand coverage of possible statistical chart types

• Violin plots

What else?

What other top-level categories are there to call out?

[joelostblom]

This is great! Thanks for getting is started! I think one more big area in my mind is shortcuts for commonly used compound charts #2789 to make it more convenient to use altair for exploratory data analysis and promote best practices by making it easy to create some charts (e.g. plots of missing values). I made some improvements recently to my experimental package Altair Ally to make it more convenient to use, but I need to spend some more time on propagating those improvements to the entire API. The discussion is also still open as to whether we want to add these types of chart or not, although I'm personally in favor.

Under "Gridded data support", I think being able to display images/heatmaps/gridded data more effectively (both in terms of syntax and performance) in general would be helpful (not just via xarray). There is some discussion on this in vega/vega-lite#6043 (also linked below). Other packages, e.g. Holoviews, Plotly, and Plot, often have a dedicated image/raster marks and sections in their documentation dedicated for how to work with images. I think this could be quite helpful in Altair as well.

Under "Coverage of statistical charts" I would add 2D densities in addition to violin charts (link to the violin issue in VL vega/vega-lite#3442). I think these are the main two missing chart types in Altair that are commonly used. Long term, I would also like something like vega/vega-lite#8067 which I think is close to gold standard when comparing multiple distributions. I like that we have these on the Altair roadmap to illustrate that they are important for Altair, but in the final version of the roadmap we should maybe add some indication that they actually need to be fixed in Vega-Lite.

[mattijn]

Thanks for starting this @jonmmease! A few more things that came in to my mind.

Syntax

• Improve syntax how to create an Altair condition with two or more predicates.
• Explore option of a new operator * for modular compositing of sub components. See also https://brucala.github.io/Deneb.jl/dev/ made by @brucala.
• Formalize (alias) functions how to get data out of the chart —> alt.Chart().to_<format>.

Documentation

• Incorporate a conceptual guide with best practices of effective data communication.
• Update and extend the tutorial section with existing outdated materials.
• Include usage guide with materials on best practices for publishing your Altair chart in a research paper, your website, embedded dashboard, interactive platforms.
• Domain specific packages build on Altair. Develop examples how to build Altair-based domain specific modules. Eg. Altair for soccer analytics etc. (altair_tiles might serve as an example of how to do this API-wise).
• Documentation on the available Altair expressions.

[brucala]

@mattijn About composing using the * operator. I created Deneb.jl as a response to the VegaLite.jl stalled PR linked above. I think it provides a very elegant way of constructing and manipulating charts. I would love to see some of those ideas on Altair.

[mattijn]

Thank you for responding @brucala! I was not yet aware of Deneb.jl. I'll update the reference. Very interesting syntax that you have explored.

If you still have some experiences that you can share that might be useful for someone that wants to start working on this. That would be great!

Thanks again for responding!

[brucala]

@mattijn These are the first things that come to mind:

• Ordering. If you do spec1 * spec2 and both specs have a shared property then you have to decide which one takes precedence. In Deneb.jl I chose to give precedence to the right-hand spec. In my mind the right-hand precedence choice is more aligned with Altair's method syntax, e.g. base_chart.method(property=new_value) where method is any arbitrary method that sets the property property (which could have been already defined in base_chart) to a new value.
• Composing with multi-views. Multi-views (like layers) can have properties (e.g. data, encoding, transform, params, ...) that can be defined within each of the single-views making the multi-view or at the top-level (affecting all single views). When one does things like data * (chart1 + chart2), the data could define the top level data property or the data properties of each single chart. The choice in Deneb.jl is that single_view_chart * multi_view_chart composes the single_view properties at top-level (when there is ambiguity), while multi_view_chart * single_view_chart composes the single_view properties with each single view of the multi_view_chart. The rationale of this choice is similar to the ordering in the point above, giving precedence to the right-hand side of compositions (because single-view properties in Vega-Lite have precedence over top-level properties). Caveat: Deneb.jl is very new and all this is very experimental (and not even documented yet 😞), however while creating the gallery examples things seem to work nicely.

[mattijn]

Thank you @brucala! This is al very interesting! Thank you for documenting this. I like the consistency!

[jonmmease]

Thanks @joelostblom and @mattijn, I'll start pulling this together. Unless there are other ideas, I was picturing creating a new top-level "Roadmap" section in the documentation next to "Release Notes".

An alternative would be to add an "About" section for:

• "Roadmap"
• "Code of Conduct"
• "Governance" (placeholder for now, fill in the future)

Let me know if anyone has opinions on this. Also @binste, let us know if you have any areas to add!

[binste]

Thank you for putting this together! It already looks great and I will try to provide my inputs as well although I won't get to it before next week. I like the idea of an "About" section in the documentation with the 3 parts you mentioned.

[mattijn]

+1. The About section could also include a section on contributing.

[jonmmease]

On the topic of gridded/image data, came across this approach to rendering rgba images as vega-lite rect marks.

https://observablehq.com/@amitkaps/image-pixel-render-with-vega-lite

Performance may be an issue, but it could be interesting to provide an imshow-like functionality that does something along these lines.

[jonmmease]

Yes, any solution that has the full data within the JSON specification won't scale.

My hypothesis is that if we convert gridded data to flattened tabular data (basically a sparse representation with one grid element per row), then serialize tabular data as binary arrow IPC format (as we'll be able to do in JupyterChart), then render rect marks with GPU acceleration, it would scale pretty far (to the order of millions of grid elements).

To render grids larger than that, some form of aggregation would be required to combine all of the grid elements that fall into a pixel, and I think VegaFusion could handle this today if we convert data to the sparse tabular arrow representation first.

I'm not opposed to native gridded data support in Vega and VegaFusion, but I think we can do a lot on the Altair side by transforming gridded data into sparse tabular.

[mattijn]

Let's do some experiments and see how far we can push it. I always used the following basic utility function for quantitative 2D array data.

def plot_array(A, scheme="purples", step=1, title="titel array"):
    import numpy as np
    import altair as alt
    import pandas as pd

    alt.data_transformers.disable_max_rows()
    Ny, Nx = A.shape
    z = A
    y, x = np.meshgrid(range(Ny), range(Nx))
    source = pd.DataFrame({"x": x.ravel(), "y": y.ravel(), "z": z.T.ravel()})

    c = (
        alt.Chart(source)
        .mark_rect(tooltip=True)
        .encode(
            x=alt.X("x:O", axis=None),
            y=alt.Y("y:O", axis=None),
            color=alt.Color("z:Q", title=title, scale=alt.Scale(scheme=scheme)),
        )
        .properties(width=alt.Step(step), height=alt.Step(step))
    )
    return c

[jonmmease]

Yeah, that's the idea I had in mind. What do you find to be the current upper limit, in terms of number of array elements, for the current Altair architecture?

[mattijn]

I don't think I've pushed the limits. I preprocess my arrays so they stay in between a few hundred by a few hundred pixels to still guarantee some responsiveness (a 500x500 array is already 250K rows in tabular form)

[joelostblom]

If performance and frame size reasonable, I like the idea of having a imshow-like macro that is convenient to use and does something like this behind the scenes. I was trying to do something similar when I tried creating a datashader image example here #1752 (comment)

[mattijn]

After seeing #262 again, I was surprised that that comment got so many reactions.
I'm wondering if we can use comment appreciation within the Altair repository to find topics for opportunities to improve the documentation. The following visual shows all comments that got equal or more than 3 reactions.

Click here for interactive version in Vega-Editor:
Screenshot:

• fill color is the number of reactions on a comment,
• stroke color is the actual GH issue number (to get a bit insight on the age of the issue),
• ctrl+click href goes to the specific comment in a new page

[ChristopherDavisUCI]

This is super cool @mattijn! How did you get the underlying data, did it require web-scraping, or is it available more directly?

[mattijn]

Thanks Chris! Unfortunately it requires scraping to get insight on comments, I used https://github.com/PyGithub/PyGithub.

[joelostblom]

This is creative, really nice @mattijn ! We could use this to find what would be helpful to document more clearly for comments/workarounds in closed issues, and to some extend to see what are desired new features in still open issues.