The simplest way to create a Torque time-lapse animation is to upload the data to a CartoDB account, then select the Torque option from the visualization wizard. Here’s an example of L.A. rapid buses.
CartoDB visualizations can also be embedded on other pages. The CartoDB Torque tutorial page contains an embedded Torque animation.
Here’s a heatmap version of the SEPTA real-time bus data, in a CartoDB visualization.
The layer is defined with the user name of a CartoDB account to use, the name of the table to
visualize from the CartoDB account, and some special CartoCSS to define aspects of the animation.
Here’s an example from the Torque project
GitHub Pages. The source
is under the project’s
This presentation walks through setting up a stand-alone Torque animation.
Torque is part of the suite of projects that make up the CartoDB web service. It’s designed to work with the other projects, particularly the Windshaft tiler and SQL API service. Torque queries the SQL API when initializing to get metadata about the table, such as the time period covered and bounding box for the points, then fetches the animation from Windshaft.
The Torque animation is configured using special CartoCSS, defining aspects such as frame count, animation duration, and the color and size of the markers used at different frame offsets.
CartoDB has several open-source components:
Working on a volunteer project, CyclePhilly. Already had a Windshaft server with PostGIS-enabled database displaying trips; wanted to add Torque animations.
Torque only really needs the Windshaft tiler and SQL API CartoDB projects to work. The Torque and Windshaft projects can be used without modification.
The SQL API will need to be set up to operate without user credentials from the CartoDB web app. I’ll share a fork of the project I’ve configured to work as a stand-alone SQL API.
Note that redis is a dependency of both Windshaft and the SQL API; it’s used for caching.
The database is the one other component we’ll need.
PostGIS-enables Postgres database
There are a number of CartoDB functions in this project
that Torque and the SQL API will expect to be defined. (The triggers are unnecessary.)
The scripts may be found here
scripts-available directory. In particular,
Allow local database connections via password authentication. Edit
pg_hba.conf and change:
local all all peer
local all all md5
Four columns are needed:
geom, in EPSG 4326. (The SQL API has a hard-coded reference to the geometry column for the table. It was
the_geom, but I renamed it in my fork.)
the_geom_webmercator, in EPSG 3857. (The Torque library has this column name hard coded for use in querying Windshaft.) I’ve found it necessary to fill this column by using the CartoDB function
CDB_TransformToWebmercatorinstead of using the PostGIS
Minimal example configuration files are in the project, in
Here is an example configuration file for a stand-alone Windshaft configuration that will work for torque.
The configuration defines the database name, database username and password, and for this, we’ll define the database table to use.
To run, put your configuration file in the top-level directory, then start with:
Once the SQL API is set up to operate without user credentials from Redis or user and database names from the subdomain, we’re ready to go! Here’s a fork of the SQL API that has the authentication parts removed. For permissions, we can rely on using a database role that has read-only access to just the table with our data for Torque.
The SQL API configuration files live in
development.js, and edit:
db_pubuser(can be the same)
statsdblock; we won’t be needing it
healthcheck block at the end, change the username to our database user.
node app.js from the project top-level directory.
cumulative. (By default, previous values are discarded.)