boundaryQuerySource
Last updated
Was this helpful?
Last updated
Was this helpful?
You can use boundaryQuerySource to build layers and widgets using a combination of:
Properties: A custom SQL query to your data warehouse that returns points.
Boundaries: A pre-generated tileset in your data warehouse that contains the polygon boundaries that will be used to aggregate the properties.
Learn more about building highly-performant large-scale boundaries visualization in our .
tilesetTableName: The fully qualified name (FQN) of the table that will contain the polygon-based boundaries in your visualization. For example, for a BigQuery connection, carto-data.my_tilesets.zipcodes_boundaries
would be a valid boundaries table name.
propertiesSqlQuery: A custom SQL query that returns the point-based properties in your visualization. You should use valid syntax for your data warehouse, which allows you to use all kinds of advanced processing directly in the data source. For example, for a BigQuery connection, SELECT * FROM carto-demo-data.demo_tables.chicago_crime_sample LIMIT 100
would be a valid SQL query.
columns (optional): The list of columns to retrieve from the table specified in propertiesSqlQuery
. Useful to increase performance and optimize query costs in queries with a large number of columns. By default, all columns will be retrieved.
filtersLogicalOperator (optional): Indicates whether filters
are applied following an AND
logic or an OR
logic.
queryParameters (optional): If your sqlQuery
contains query parameters, pass the values for each parameter in this field, following your data warehouse mechanism for query parameters, like named or positional parameters.
boundaryQuerySource
is compatible with the following layers from the @deck.gl/carto
module:
boundaryQuerySource
is not compatible with widgets.
filters (optional): A valid object, used to perform server-side filtering of this data source with column-based filters.
The response of boundaryQuerySource
is a promise that can be resolved and used in .
A recommended workaround is to use a using the same properties, attached to the . The same can then be attached to both your vector source and your boundary source.
queryParameters
and parameterized queriesCARTO uses the native mechanisms available in each data warehouse to build parameterized queries, which prevents any SQL injection.
Therefore, to specify the parameters in the query and the expected syntax for queryParameters
, you will need to use the specific providers' syntax:
BigQuery
BigQuery uses named parameters.
Please note that empty arrays are not supported as parameter values.
Snowflake
Snowflake supports positional parameters, such as:
Redshift and PostgreSQL
Snowflake supports positional parameters, such as: