Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
These tutorials introduce you to common Vega specification patterns so you can start creating visualizations quickly and easily. Each tutorial uses a code example that demonstrates a particular Vega feature or pattern. The Getting Started with Vega tutorial covers basic Vega concepts and serves as the foundation for some of the tutorials that follow, and introduces you to the API for communication with the backend. Other tutorials provide more in-depth information about specific Vega implementations.
Use these tutorials to gain a better understanding of Vega by experimenting with them to create new visualizations on your own HEAVY.AI system and database. You can also Try Vega to make adjustments to Vega code and see real-time changes in charts.
For information about the Vega specification syntax and properties, see Vega Reference.
Because the tutorials focus on the Vega specification, they use a simple client implementation that sends the render request to the HEAVY.AI server and handles the response:
Common index.html
Common vegademo.js
The renderVega() function sends the exampleVega JSON structure described in the tutorials. Getting Started with Vega covers Vega library dependencies and the renderVega() function in more detail.
On a connection error, you can view the error message to determine the cause of the error. To determine the cause of Vega specification errors, catch and handle the renderVega() exception.
Vega at a Glance - Provides an overiew of Vega and a simple example to visualize tweets.
Getting Started with Vega - Maps a continuous, quantitative input domain to a continuous output range. Uses the same visualization as Vega at a Glance, but elaborates on the runtime environment and implementation steps.
Getting More from Your Data - Builds on the Getting Started with Vega tutorial by color-coding tweets according to language.
Creating More Advanced Charts - Introduces Symbol Type marks by creating a heatmap visualization of political donations.
Using the Poly Marks Type - Shows how to use the Polys Type marks, which uses an implicit polygon data table format. The visualization in the tutorial is a map of zip codes, color-coded according to average political contribution amount.
Vega Accumulator - Describes the three modes of accumulation rendering and provides some implementation examples. The data used contains information about political donations, including party affiliation, the amount of the donation, and location of the donor.
Using Transform Aggregation - Shows how to create Vega-based visualizations with render properties that are driven by aggregated statistics. Use Vega transform aggregation and formula expressions to automate the process of gathering statistical information about a rendered query.
Improving Rendering with SQL Extensions - Describes how to use SQL extension functions in Vega to map meters to pixels and improve map rendering.
Accumulation works by aggregating data per pixel during a backend render. Data is accumulated for every pixel for every shape rendered. Accumulation rendering is activated through color scales – scales that have colors defined for their range.
Note: Currently, only the COUNT aggregation function is supported.
This topic describes accumulation rendering and provides some implementation examples. The data source used here – a table called contributions – contains information about political donations made in the New York City area, including party affiliation, the amount of the donation, and location of the donor.
There are three accumulation modes:
Density accumulation performs a count aggregation by pixel. It allows you to color a pixel by normalizing the count and applying a color to it, based on a color scale. In Heavy Immerse, if you open or create a Pointmap chart, you can toggle density accumulation on and off by using the Density Gradient attribute. For more information, see Pointmap.
Note: Blend and percentage accumulation are not currently available in Heavy Immerse.
The density mode examples use the following base code:
This code generates the following image:
All points are rendered with a size of 2 and colored according to the contribution amount:
$100 or less is colored blue.
$10,000 or more is colored red.
Anything in between is colored somewhere between blue and red, depending on the contribution. Amounts closer to $100 are more blue, and amounts closer to $10,000 are more red.
The examples that follow adjust the pointcolor scale and show the effects of various adjustments. Any changes made to Vega code are isolated to that scale definition.
Density accumulation can be activated for any scale that takes as input a continuous domain (linear, sqrt, pow, log, and threshold scales) and outputs a color range. In the following code snippet, the density accumulator has been added to the linear pointcolor scale:
The final color at a pixel is determined by normalizing the per-pixel aggregated counts and using that value in the scale function to calculate a color. The domains of density accumulation scales should be values between 0 and 1 inclusive, referring to the normalized values between 0 and 1. The normalization is performed according to the minDensityCnt and maxDensityCnt properties. After normalization, minDensityCnt refers to 0 and maxDensityCnt refers to 1 in the domain. In this case, 0 in the domain equates to a per-pixel count of 1, and 1 in the domain equates to a per-pixel count of 100.
minDensityCnt and maxDensityCnt are required properties. They can have explicit integer values, or they can use keywords that automatically compute statistical information about the per-pixel counts. Currently available keywords are:
min
max
1stStdDev
2ndStdDev
-1stStdDev
-2ndStdDev
If you change the color scale to the following:
The minimum aggregated count of all the pixels is used as the minDensityCnt, and the maximum aggregated count used as the maxDensityCnt. This results in the following:
Notice that the area with the most overlapping points is in the upper east side of Manhattan.
Now, use +/- 2 standard deviations for your counts:
This produces the following:
In this example, the scale is changed to a threshold scale, and the colors are adjusted to create a more interesting image:
This results in:
Note: You can mix and match explicit values and keywords for minDensityCnt and maxDensityCnt. However, if your min value is greater than your max value, your image might look inverted.
Blend accumulation works only with ordinal scales. This accumulation type blends the per-category colors set by an ordinal scale so that you can visualize which categories are more or less prevalent in a particular area.
The following Vega code colors the points according to the value in the recipient_party column:
This results in the following chart:
Each point is colored according to recipient party. Values of R (republican) are colored red, D (democrat) are colored blue, and everything else is colored green.
To activate blend accumulation, add the "accumulator": "blend" property to an ordinal scale.
This generates the following chart:
Activating blend accumulation shows you where one party is more dominant in a particular area. The COUNT aggregation is now being applied for each category, and the colors associated with each category are blended according to the final percentage of each category per pixel.
Note: Unlike in density mode, a field property is required in mark properties that reference blend accumulator scales.
Percentage (pct) mode can help you visualize how prevalent a specific category is based on a percantage. Any scale can be used in percentage mode, but the domain values must be between 0 and 1, where 0 is 0% and 1 is 100%.
Using the political donations database, you can determine where the recipient_party of “R” (republican) is more prevalent.
Here’s the color scale:
And the resulting image:
Using the threshold scale, anything colored blue is between 0%-33% republican, purple is 33%-66% republican, and red is 66%-100% republican.
pctCategory is a required property for percentage mode and can be numeric or a string. A string refers to a string value from a dictionary-encoded column.
You can modify the example to use a numeric value for pctCategory. First, modify the SQL in the Vega to select the contribution amount for each data point:
Now use the amount as the driving field for the pct accumulator scale:
Now, change the pct scale to the following:
This results in the following output, showing where thousand-dollar contributions are most prevalent:
You can use the pctCategoryMargin property to buffer numeric pctCategory values, so you can use a range for the numeric category.
You can create Vega-based visualizations with render properties that are driven by aggregated statistics. You can use Vega transform aggregation and formula expressions to automate the process of gathering statistical information about a rendered query. By doing so, you do not have to run an SQL prequery to get the information, thereby reducing the time it takes to process and render a chart.
The following examples show how to use transforms in Vega to do the following:
Render a heatmap that is colored using dynamic statistics of the bins
Create a geo pointmap with different transform modes
NOTE: You can see Vega examples in the OmniSci Vega Editor. For more information about the OmniSci Vega engine, see Try Vega.
The following heatmap example demonstrates the benefits of Vega transforms for performance and reducing redundancy:
First, the example shows using an SQL expression to render a heatmap, as well as an additional expression to color the hexagonal bins according to the min and max of the cnt value of the aggregated bins from the query.
Then, you will see how to render the heatmap and color the bins directly in Vega by using source data definitions and performing aggregation transforms on that data, decreasing chart rendering time and redundancy.
The following is a typical SQL query used for rendering a hexagonal heatmap:
To color the hexagonal bins according to the min and max of the cnt value of the bins from the query, you need to run a prequery to gather these statistics manually. Here, this is done using a subquery SQL statement:
The values returned from this query can then be embedded in the Vega code to color the heatmap bins. Notice that the second query does an aggregation over the query, effectively running the query twice.
To avoid the redundancy and expense of running the query twice, you can instead specify the aggregation in Vega.
The following Vega code renders the heatmap colored by aggregated statistics using transforms.
The data section named heatmap_stats has a source data table defined by the "source": "heatmap_query" line:
The "heatmap_stats" data takes as input the "heatmap_query" data, which is the data supplied by the SQL query. Use the source data type to apply intermediary steps or expressions (transforms) to the input source data.
For information about syntax and requirements for the source and transform properties, see the Data property.
To color the data according to the range of values defined by two standard deviations from the mean, edit the "heatmap_stats" section as follows to:
Aggregate the minimum, maximum, average, and sampled standard deviation of the count column.
Use formula expressions to calculate values that are two standard deviations from the average.
Then, reference these values in the scale domain:
Performing these calculations in Vega improves performance because the SQL query is only run once and the aggregated statistics are done “on the fly.” Because the query is not repeated in a statistical prequery step, you can reduce the full render time by half by performing the statistics step in Vega at render time.
This section shows how to use Vega tranforms to drive the color and size of points in a geo pointmap. Specifically, it show examples using the following aggregation transforms:
distinct: An array of distinct values from an input data column.
median: The median of an input data column.
quantile: An array of quantile separators; operates on numeric columns and takes the following pameters:
numQuantiles: The number of contiguous intervals to create; returns the separators for the intervals. The number of separators equals numQuantiles - 1.
includeExtrema: Whether to include min and max values (extrema) in the resulting separator array. The size of the resulting separator array will be numQuantiles + 1.
As with the heatmap example described earlier, using Vega transforms eliminate the need for an SQL prequery and significantly improves performance for dynamic operations.
The examples that follow use a Twitter dataset to create a geo pointmap.
For more information about the aggregate functions used in these examples, see transforms in the Vega Data reference.
In the following example, the size of the points in a geo pointmap are defined by the numeric range two standard deviations from the average number of followers of the input data. The color of the points is driven by the distinct languages of the input data. To calculate the distinct languages, you could run a prequery using DISTINCT and then populate a Vega color scale with the results. However, the query would need to be run before every render update if the distinct data is meant to be dynamic, which would be very costly.
With the distinct Vega transform, this can be performed when evaluating the Vega code in the backend, so you do not need to run the prequery. This can improve performance considerably.
This Vega code results in this image:
Outliers in a dataset can significantly skew statistics such as AVG and STDDEV. To mitigate this, you can use median and quantile to create a more meaningful probability distribution of the data. Median and quantiles are computed dynamically when Vega is evaluated and can be used to drive different render properties.
The following hexmap example uses median to drive the color of the hex bins. Notice in the final render that roughly half of the bins are colored red, and the other half are blue.
The quantile function takes two additional parameters:
numQuantiles is the number of contiguous intervals to create and returns the separators for the intervals. The number of returned separators is numQuantiles - 1.
includeExtrema is a true or false value indicating whether to include the extrema (min and max) in the resulting separator array. If true, the number of returned values is numQuantiles + 1.
To see how a quantile works, consider a query that results in this set of values for "followers":
{3, 6, 7, 8, 8, 10, 13, 15, 16, 20}
With a quantile operator defined as {"type": "quantile", "numQuantiles": 4}, the result of the operator would be the following array:
[7, 9, 15]
25% of the data has less than 7 followers, 25% has between 7 and 9, 25% has between 9 and 15, and 25% has more than 15.
With a quantile operator defined as {"type": "quantile", "numQuantiles": 4, "includeExtrema": true}, the result of the operator would be the following array:
[3, 7, 9, 15, 20].
With "includeExtrema" == true, the min and max are included in the resulting array, so 25% of the data has between 3 and 7 followers, 25% has between 7 and 9, 25% has between 9 and 15, and 25% has between 15 and 20.
The following Vega code snippet gets the octiles (8-quantiles) and sextiles (6-quantiles) of a column called "followers":
For more information about quantiles, see: https://en.wikipedia.org/wiki/Quantile.
Here is a more complete example using sextiles. Notice in the resulting image approximately the same number of hexagons appears in each of the six quantile groups colored blue to red, from left to right.
Marks defined in Vega specify how to render data-backed geometric primitives for a visualization. Because these are visual primitives, the default units for defining position and size are in pixels. Pixel units usually are not directly representable by the data space, so the driving data must be mapped to pixel space to be used effectively. In many cases, this data space-to-pixel space mapping can be handled with scales. However, in a number of instances, particularly in geo-related cases, you want to size the primitives in world space units, such as meters. These units cannot be easily converted to pixel units using Vega scales.
This tutorial describes how to use available SQL extension functions in Vega to map meters to pixels, thereby improving map rendering.
Let's look at a basic example. The following uses a public polical contributions dataset, and draws circles for the points positioned using the GPS location of the contributor. The circles are colored by the recipient's political party affiliation and sized to be 10 pixels in diameter:
The resulting render, composited over a basemap courtesy of Mapbox, looks like this:
Because the circles are sized using pixels, if you zoom in, the circles stay sized at a fixed 10 pixels. The size of the dots does not stay relative to the area of the map originally covered:
The resulting render in this case looks like this:
To keep the size of the points relative to an area on the map, you need to define the size of the pixels in meters. Currently, Vega does not provide a scale that maps meters in a mercator-projected space to pixel units. To bypass this limitation, you can use an OmniSci extension function that performs meters-to-pixels conversion using a mercator-projected space.
For scalar columns, such as lon/lat, use the following:
For geo POINT columns, you use:
Because the extension functions can only return scalar values, each dimension (width and height) must have its own extension function.
To apply these functions to the previous example, add these extension functions to your SQL code, and use the results of the extension functions to determine the width and height of the circles. The following example sizes the points to 1 km in diameter:
Note the differences in this Vega code compared to the earlier example; two projections were added to the SQL code:
convert_meters_to_merc_pixel_width(1000, lon, lat, -119.49268182426508, -76.518508633361, 1146, 1) as width
convert_meters_to_merc_pixel_height(1000, lon, lat, 21.99999999999997, 53.999999999999716, 1116, 1) as height
This converts 1 km to a pixel value in width/height based on the current view of a mercator-projected map.
The width/height calculated here is now used to drive the width/height of the circle using this JSON in the Vega mark:
The resulting render looks like this:
Now, if you zoom in, the size of the points stays relative to the map:
...with the following resulting render:
The following code zooms in a bit more:
and results in the following render:
Notice that the WHERE clause of the SQL filters out points not in view:
However, when zoomed in far enough, a point can disappear, even though its associated circle is still in view. This occurs because only the center of the circle is checked in this filter and not the whole rendered circle.
To illustrate this, consider a render of the following query:
The resulting image looks like this:
If you pan to the left, the blue dot disappears, although it should still be visible. Here is the query:
...and the resulting image:
To alleviate this issue, you can use the extension functions as a filter:
For scalar columns (such as lon/lat): is_point_size_in_merc_view
For geo POINT columns: is_point_size_in_view
These extension functions take as arguments the parameters of the view along with the point size in meters, and return true if the point is in the defined view, or false otherwise.
Refering back to the original example, replace the WHERE clause with its is_point_size_in_merc_view equivalent:
This results in:
Now, pan slightly to the left again:
The result is:
Notice that the blue dot now passes the filter and stays in view.
This approach is not an accurate representation of area on a map. It provides a reasonable approximate, but more error is introduced as you approach the poles, because this approach works only in two dimensions. As you approach the poles, you would realistically see areas that are oblong and egg-shaped. However, this approach works reasonably well for most inhabitable geo locations.
The symbol mark types are procedurally generated and use a simple POINT primitive in the underlying graphics API. This primitive has a maximum pixel size for this primitive. The limit is graphics driver–implementation defined, but testing shows this limit to be 2000 pixels in diameter. This limit can have an effect if you zoom in tight on areas where the circles have large areas. You may see points disappear, similar to the filtering issue described earlier. This most likely occurs because the ultimate width/height generated by the convert_meters_to_pixels extension functions exceed this limit.
As a workaround, use the legacysymbol mark type instead of symbol. The legacysymbol mark type does not render the shape procedurally, so it is not affected by this limit. The legacysymbol mark was deprecated in favor of the improved rendering performance of the procedural approach.
When you use extension functions in SQL, you cannot use Vega scales to do further mapping; for example, you cannot use the contribution "amount" column to drive the size of the points in meters with a Vega scale. Any additional mapping must be done in the SQL, which may not be trivial depending on the complexity of the mapping.
Source code can be found at the end of this tutorial.
This tutorial introduces you to the Polys Type marks, which uses an implicit polygon data table format. The visualization is a map of zip codes color-coded according to average contribution amount. The data table encodes polygons representing zip code areas.
See the Poly Map with Backend Rendering charting example for a programmatic rendering of this visualization.
The following data property extracts the average contribution amount from the contributions_donotmodify data table, omitting rows that do not have a contribution amount:
When working with polygon data, the "format": "polys" property must be specified.
The scales specification scales x values to the visualization area width and y values to the height. A color scale, polys_fillColor is also specified that linearly scales nine contribution amount ranges to nine colors:
Zip code areas for which average contribution amounts are not specified by the domain are color-coded green.
The marks property specifies visually encoding the data from the polys data table as polygons:
Polygon x and y vertex locations are transformed to the visualization area using the x and y scales.
The x and y polygon vertex locations are implicitly encoded in the data table as described in Polys Type.
Polygon fill color color-codes the average contribution amount, avgContrib, linearly scaled by the polys_fillColor scale:
Finally, the marks property specifies the polygon border width and color, and line join constraints:
Working with Polys Tutorial Directory Structure
Working with Polys Tutorial index.html
Working with Polys Tutorial vegademo.js
Working with Polys Tutorial vegaspec.js
Source code is located at the end of the tutorial.
This tutorial uses the same visualization as Vega at a Glance but elaborates on the runtime environment and implementation steps. The Vega usage pattern described here applies to all Vega implementations. Subsequent tutorials differ only in describing more advanced Vega features.
This visualization maps a continuous, quantitative input domain to a continuous output range. Again, the visualization shows tweets in the EMEA region, from a tweets data table:
Backend rendering using Vega involves the following steps:
You can create the Vega specification statically, as shown in this tutorial, or programmatically. See the Poly Map with Backend Rendering charting example for a programmatic implementation. Here is the programmatic source code:
A Vega JSON specification has the following general structure:
The width and height properties define the width and height of your visualization area, in pixels:
This example uses the following SQL statement to get the tweets data:
The input data are the latitude and longitude coordinates of tweets from the tweets_nov_feb data table. The coordinates are labeled x and y for Field Reference in the marks property, which references the data using the tweets name.
The marks property specifies the graphical attributes of how each data item is rendered:
In this example, each data item from the tweets data table is rendered as a point. The points marks type includes position, fill color, and size attributes. The marks property specifies how to visually encode points according to these attributes. Points in this example are three pixels in diameter and colored blue.
Points are scaled to the visualization area using the scales property.
The following scales specification maps marks to the visualization area.
Both x and y scales specify a linear mapping of the continuous, quantitative input domain to a continuous output range. In this example, input data values are transformed to predefined width and height range values.
Later tutorials show how to specify data transformation using discrete domain-to-range mapping.
Use the browser-connector.js renderVega() API to communicate with the backend. The connector is layered on Apache Thrift for cross-language client communication with the server.
Follow these steps to instantiate the connector and to connect to the backend:
Include browser-connector.js located at https://github.com/omnisci/mapd-connector/tree/master/dist to include the MapD connector and Thrift interface APIs.
Instantiate the MapdCon() connector and set the server name, protocol information, and your authentication credentials, as described in the MapD Connector API:
Finally, call the MapD connector API connect() function to initiate a connect request, passing a callback function with a (error, success) signature as the parameter.
For example,
The connect() function generates client and session IDs for this connection instance, which are unique for each instance and are used in subsequent API calls for the session.
On a successful connection, the callback function is called. The callback function in this example calls the renderVega() function.
The MapD connector API renderVega() function sends the Vega JSON to the backend, and has the following parameters:
The backend returns the rendered Base64 image in results.image, which you can display in the browser window using a data URI.
Getting Started Directory Structure
Getting Started index.html
Getting Started vegademo.js
Getting Started vegaspec.js
Source code is located at the end of this tutorial.
This tutorial introduces you to Symbol Type marks by creating a heatmap visualization. The heatmap shows contribution level to the Republican party within the continental United States:
The contribution data are obtained using the following SQL query:
The visualization uses a Symbol Type marks type to represent each data item in the heatmap_query data table:
The marks properties property specifies the symbol shape, which is a square. Each square has a pixel width and height of one pixel.
Notice that the data x and y location values do not reference a scale. The location values are the values of the SQL query, transformed using extension functions.
The fill color of the square uses the heat_color scale to determine the color used to represent the data item.
Quantize scales are similar to linear scales, except they use a discrete rather than continuous range. The continuous input domain is divided into uniform segments based on the number of values in the output range.
A heatmap shows a continuous input domain divided into uniform segments based on the number of values in the output range. This is a quantize scales type. In the example, dollar amounts between $10,000 and $1 million are uniformly divided among 21 range values, where the larger amounts are represented by brighter colors.
Values outside the domain and null values are rendered as dark blue, #0d0887.
Advanced Chart Type Tutorial Directory Structure
Advanced Chart Type Tutorial index.html
Advanced Chart Type Tutorial vegademo.js
Advanced Chart Type Tutorial vegaspec.js
Source code is located at the end of this topic.
This tutorial provides an overiew of Vega and a simple example to visualize tweets in the EMEA geographic region:
The Vega JSON structure maps data to geometric primitives.
A first task is to specify the data source. You can either define data statically or use a SQL query. This examples uses a SQL query to get tweet geolocation information from a tweets database:
The resulting SQL columns can be referenced in other parts of the specification to drive visualization elements. In this example, the projected columns are goog_x and goog_y, which are renamed x and y, and rowid, which is a requirement for hit-testing.
The Vega specification for this example includes the following top-level properties:
height and width, which define the height and width of the visualization area.
data, which defines the data source. The SQL data described above is defined here with the label tweets for later referencing.
marks, which describes the geometric primitives used to render the visualization.
scales, which are referenced by marks to map input domain values to appropriate output range values.
Here is the full Vega specification used in this example:
The following sections describe the top-level Vega specification properties.
The width and height properties define a visualization area 384 pixels wide and 564 pixels high:
The scales position encoding properties map the marks into this visualization area.
The marks property defines visualization geometric primitives. The OmniSci Vega implementation defines the following primitive types:
lines A line
points A point
polys A polygon
symbol A geometric symbol, such as a circle or square
Each primitive type has a set of properties that describe how the primitive is positioned and styled.
This example uses points to represent the tweets data:
Points support the following properties; not all are included in the example:
x The x position of the point in pixels.
y The y position of the point in pixels.
z The depth coordinate of the point in pixels.
fillColor The color of the point.
fillOpacity The opacity of the fill, from transparent (0) to opaque (1).
opacity The opacity of the point as a whole, from transparent (0) to opaque (1).
size The diameter of the point in pixels.
The points in the example reference the tweets SQL data and use the x and y columns from the SQL to drive the position of the points. The positions are appropriately mapped to the visualization area using scales as described in Scale Input Domain to Output Range. The fill color is set to blue and point size is set to three pixels.
The scales definition maps data domain values to visual range values, where the domain property determines the input domain for the scale. See the d3-scale reference for background information about how scaling works.
This example uses linear scales to map mercator-projected coordinates into pixel coordinates for rendering.
The x and y scales use linear interpolation to map point x- and y-coordinates to the width and height of the viewing area. The width and height properties are predefined keywords that equate to the range [0, <current width>] and [0, <current height>].
After completing the Vega specification, you send the JSON structure to the backend for rendering.
The following steps summarize the rendering and visualization sequence:
Instantiate the MapdCon object for connecting to the backend.
Call the connect method with server information, user credentials, and data table name.
Provide the renderVega() callback function to connect() and include the Vega specification as a parameter.
Display the returned PNG image in you client browser window.
OmniSci uses Apache Thrift for cross-language client communication with the backend. Include the browser-connector.js, connector API, which includes Thrift interface libraries and the renderVega() function:
The following example encapsulates the connect, render request, and response handling sequence:
This example demonstrated the basic concepts for understanding and using Vega. To become comfortable with Vega, try this example using your own OmniSci instance, changing the MapdCon() parameters according to match your host environment and database.
As you gain experience with Vega and begin writing your own applications, see the Reference for detailed information about Vega code.
Vega at a Glance index.html
Source code can be found at the end of this tutorial.
This tutorial builds on the Getting Started with Vega tutorial by color-coding tweets according to language:
Tweets in English are blue.
Tweets in French are orange.
Tweets in Spanish are green.
All other tweets are light or dark gray.
To highlight language in the visualization, the example specifies the language column query in the Vega data property, and associates language with color.
The Scales property maps the language abbreviation string to a color value. Because we want to map discrete domain values to discrete range values, we specify a color scale with an ordinal type scale:
You can specify a default color values for values not specified in range and for data items with a value of null. In this example, tweets in languages other than English, Spanish, or French are colored gray and tweets with a language value of null are colored light gray (#cacaca).
Similar to using x and y scales to map Marks property x and y fields to the visualization area, you can scale the fillColor property to the visualization area.
In previous examples the fill color of points representing tweets was statically specified as blue:
This example, uses Value Reference to specify the fill color:
The fillColor references the color scale and performs a lookup on the current language value, from the color data table field.
Getting More Insight Tutorial Directory Structure
Getting More Insight Tutorial index.html
Getting More Insight Tutorial vegademo.js
Getting More Insight Tutorial vegaspec.js
Property
Description
dbName
OmniSci database name.
host
OmniSci web server name.
password
OmniSci user password.
port
OmniSci web server port
protocol
Communication protocol: http, https
user
OmniSci user name.
Parameter
Type
Required
Description
widgetid
number
X
Calling widget ID.
vega
string
X
Vega JSON object, as described in Step 1 - Create the Vega Specification.
options
number
Render query options.
compressionLevel:PNG compression level. 1 (low, fast) to 10 (high, slow). Default = 3
callback
function
Callback function with (error, success) signature.
Return
Description
Base64 image
PNG image rendered on server
