This website is for version 5. You can find the documentation for version 4 here.

Encodings#

The key to creating meaningful visualizations is to map properties of the data to visual properties in order to effectively communicate information. In Altair, this mapping of visual properties to data columns is referred to as an encoding, and is most often expressed through the Chart.encode() method.

For example, here we will visualize the cars dataset using four of the available encoding channels (see Channels for details): x (the x-axis value), y (the y-axis value), color (the color of the marker), and shape (the shape of the point marker):

import altair as alt
from vega_datasets import data


cars = data.cars()

alt.Chart(cars).mark_point().encode(
    x='Horsepower',
    y='Miles_per_Gallon',
    color='Origin',
    shape='Origin'
)

Channel Options#

Each encoding channel accepts a number of channel options (see Channel Options for details) which can be used to further configure the chart. Altair 5.0 introduced a method-based syntax for setting channel options as a more convenient alternative to the traditional attribute-based syntax described in Attribute-Based Syntax (but you can still use the attribute-based syntax if you prefer).

Note

With the release of Altair 5, the documentation was updated to prefer the method-based syntax. The gallery examples still include the attribute-based syntax in addition to the method-based syntax.

Method-Based Syntax#

The method-based syntax replaces keyword arguments with methods. For example, an axis option of the x channel encoding would traditionally be set using the axis keyword argument: x=alt.X('Horsepower', axis=alt.Axis(tickMinStep=50)). To define the same X object using the method-based syntax, we can instead use the more succinct x=alt.X('Horsepower').axis(tickMinStep=50).

The same technique works with all encoding channels and all channel options. For example, notice how we make the analogous change with respect to the title option of the y channel. The following produces the same chart as the previous example.

alt.Chart(cars).mark_point().encode(
    alt.X('Horsepower').axis(tickMinStep=50),
    alt.Y('Miles_per_Gallon').title('Miles per Gallon'),
    color='Origin',
    shape='Origin'
)

These option-setter methods can also be chained together, as in the following, in which we set the axis, bin, and scale options of the x channel by using the corresponding methods (axis, bin, and scale). We can break the x definition over multiple lines to improve readability. (This is valid syntax because of the enclosing parentheses from encode.)

alt.Chart(cars).mark_point().encode(
    alt.X('Horsepower')
        .axis(ticks=False)
        .bin(maxbins=10)
        .scale(domain=(30,300), reverse=True),
    alt.Y('Miles_per_Gallon').title('Miles per Gallon'),
    color='Origin',
    shape='Origin'
)

Attribute-Based Syntax#

The two examples from the section above would look as follows with the traditional attribute-based syntax:

alt.Chart(cars).mark_point().encode(
    alt.X('Horsepower', axis=alt.Axis(tickMinStep=50)),
    alt.Y('Miles_per_Gallon', title="Miles per Gallon"),
    color='Origin',
    shape='Origin'
)

For specs making extensive use of channel options, the attribute-based syntax can become quite verbose:

alt.Chart(cars).mark_point().encode(
    alt.X(
        'Horsepower',
        axis=alt.Axis(ticks=False),
        bin=alt.Bin(maxbins=10),
        scale=alt.Scale(domain=(30,300), reverse=True)
    ),
    alt.Y('Miles_per_Gallon', title='Miles per Gallon'),
    color='Origin',
    shape='Origin'
)

Encoding Data Types#

The details of any mapping depend on the type of the data. Altair recognizes five main data types:

Data Type

Shorthand Code

Description

quantitative

Q

a continuous real-valued quantity

ordinal

O

a discrete ordered quantity

nominal

N

a discrete unordered category

temporal

T

a time or date value

geojson

G

a geographic shape

For data specified as a DataFrame, Altair can automatically determine the correct data type for each encoding, and creates appropriate scales and legends to represent the data.

If types are not specified for data input as a DataFrame, Altair defaults to quantitative for any numeric data, temporal for date/time data, and nominal for string data, but be aware that these defaults are by no means always the correct choice!

The types can either be expressed in a long-form using the channel encoding classes such as X and Y, or in short-form using the Shorthand Syntax discussed below. For example, the following two methods of specifying the type will lead to identical plots:

alt.Chart(cars).mark_point().encode(
    x='Acceleration:Q',
    y='Miles_per_Gallon:Q',
    color='Origin:N'
)
alt.Chart(cars).mark_point().encode(
    alt.X('Acceleration', type='quantitative'),
    alt.Y('Miles_per_Gallon', type='quantitative'),
    alt.Color('Origin', type='nominal')
)

The shorthand form, x="name:Q", is useful for its lack of boilerplate when doing quick data explorations. The long-form, alt.X('name', type='quantitative'), is useful when doing more fine-tuned adjustments to the encoding using channel options such as binning, axis, and scale.

Specifying the correct type for your data is important, as it affects the way Altair represents your encoding in the resulting plot.

Effect of Data Type on Color Scales#

As an example of this, here we will represent the same data three different ways, with the color encoded as a quantitative, ordinal, and nominal type, using three horizontally-concatenated charts (see Horizontal Concatenation):

base = alt.Chart(cars).mark_point().encode(
    x='Horsepower:Q',
    y='Miles_per_Gallon:Q',
).properties(
    width=140,
    height=140
)

alt.hconcat(
   base.encode(color='Cylinders:Q').properties(title='quantitative'),
   base.encode(color='Cylinders:O').properties(title='ordinal'),
   base.encode(color='Cylinders:N').properties(title='nominal'),
)

The type specification influences the way Altair, via Vega-Lite, decides on the color scale to represent the value, and influences whether a discrete or continuous legend is used.

Effect of Data Type on Axis Scales#

Similarly, for x and y axis encodings, the type used for the data will affect the scales used and the characteristics of the mark. For example, here is the difference between a ordinal, quantitative, and temporal scale for an column that contains integers specifying a year:

pop = data.population()

base = alt.Chart(pop).mark_bar().encode(
    alt.Y('mean(people):Q').title('Total population')
).properties(
    width=140,
    height=140
)

alt.hconcat(
    base.encode(x='year:O').properties(title='ordinal'),
    base.encode(x='year:Q').properties(title='quantitative'),
    base.encode(x='year:T').properties(title='temporal')
)

Because values on quantitative and temporal scales do not have an inherent width, the bars do not fill the entire space between the values. These scales clearly show the missing year of data that was not immediately apparent when we treated the years as ordinal data, but the axis formatting is undesirable in both cases.

To plot four digit integers as years with proper axis formatting, i.e. without thousands separator, we recommend converting the integers to strings first, and the specifying a temporal data type in Altair. While it is also possible to change the axis format with .axis(format='i'), it is preferred to specify the appropriate data type to Altair.

pop['year'] = pop['year'].astype(str)

base.mark_bar().encode(x='year:T').properties(title='temporal')

This kind of behavior is sometimes surprising to new users, but it emphasizes the importance of thinking carefully about your data types when visualizing data: a visual encoding that is suitable for categorical data may not be suitable for quantitative data or temporal data, and vice versa.

Encoding Shorthands#

For convenience, Altair allows the specification of the variable name along with the aggregate and type within a simple shorthand string syntax. This makes use of the type shorthand codes listed in Encoding Data Types as well as the aggregate names listed in Binning and Aggregation. The following table shows examples of the shorthand specification alongside the long-form equivalent:

Shorthand

Equivalent long-form

x='name'

alt.X('name')

x='name:Q'

alt.X('name', type='quantitative')

x='sum(name)'

alt.X('name', aggregate='sum')

x='sum(name):Q'

alt.X('name', aggregate='sum', type='quantitative')

x='count():Q'

alt.X(aggregate='count', type='quantitative')

Escaping special characters in column names#

Seeing that Altair uses : as a special character to indicate the encoding data type, you might wonder what happens when the column name in your data includes a colon. When this is the case you will need to either rename the column or escape the colon. This is also true for other special characters such as . and [] which are used to access nested attributes in some data structures.

The recommended thing to do when you have special characters in a column name is to rename your columns. For example, in pandas you could replace : with _ via df.rename(columns = lambda x: x.replace(':', '_')). If you don’t want to rename your columns you will need to escape the special characters using a backslash:

import pandas as pd

source = pd.DataFrame({
    'col:colon': [1, 2, 3],
    'col.period': ['A', 'B', 'C'],
    'col[brackets]': range(3),
})

alt.Chart(source).mark_bar().encode(
    x='col\:colon',
    # Remove the backslash in the title
    y=alt.Y('col\.period').title('col.period'),
    # Specify the data type
    color='col\[brackets\]:N',
)

As can be seen above, indicating the data type is optional just as for columns without escaped characters. Note that the axes titles include the backslashes by default and you will need to manually set the title strings to remove them. If you are using the long form syntax for encodings, you do not need to escape colons as the type is explicit, e.g. alt.X(field='col:colon', type='quantitative') (but periods and brackets still need to be escaped in the long form syntax unless they are used to index nested data structures).

Binning and Aggregation#

Beyond simple channel encodings, Altair’s visualizations are built on the concept of the database-style grouping and aggregation; that is, the split-apply-combine abstraction that underpins many data analysis approaches.

For example, building a histogram from a one-dimensional dataset involves splitting data based on the bin it falls in, aggregating the results within each bin using a count of the data, and then combining the results into a final figure.

In Altair, such an operation looks like this:

alt.Chart(cars).mark_bar().encode(
    alt.X('Horsepower').bin(),
    y='count()'
    # could also use alt.Y(aggregate='count', type='quantitative')
)

Notice here we use the shorthand version of expressing an encoding channel (see Encoding Shorthands) with the count aggregation, which is the one aggregation that does not require a field to be specified.

Similarly, we can create a two-dimensional histogram using, for example, the size of points to indicate counts within the grid (sometimes called a “Bubble Plot”):

alt.Chart(cars).mark_point().encode(
    alt.X('Horsepower').bin(),
    alt.Y('Miles_per_Gallon').bin(),
    size='count()',
)

There is no need, however, to limit aggregations to counts alone. For example, we could similarly create a plot where the color of each point represents the mean of a third quantity, such as acceleration:

alt.Chart(cars).mark_circle().encode(
    alt.X('Horsepower').bin(),
    alt.Y('Miles_per_Gallon').bin(),
    size='count()',
    color='mean(Acceleration):Q'
)