tiler
We currently provide procedures to create the following kind of tilesets:
Spatial index tiles (aggregates spatial indexes into tiles at specific resolutions)
Geometry-based MVT tiles of two types:
simple tilesets to visualize features individually
aggregation tilesets to generate aggregated point visualizations
Visit the Tilesets section to learn more about tileset types and which procedures to use in each case.
CREATE_TILESET
Description
Creates a simple tileset. It differs from CREATE_SIMPLE_TILESET
in that the procedure performs a previous analysis in order to find automatically the right options for the tileset. It is done by extracting all the properties to be included within the tileset and sampling the data in order to avoid BigQuery limitations. Therefore, only input
and output_table
are mandatory and options
can be set to NULL
.
input
:STRING
that can either be a quoted qualified table name (e.g.`project-id.dataset-id.table-name`
) or a full query contained by parentheses (e.g.(SELECT * FROM `project-id.dataset-id.table-name`)
).output_table
: Where the resulting table will be stored. It must be aSTRING
of the form`project-id.dataset-id.table-name`
. Theproject-id
can be omitted (in which case the default one will be used). The dataset must exist and the caller needs to have permissions to create a new table on it. The process will fail if the target table already exists.options
:STRUCT<name STRING, description STRING,legend STRING, zoom_min INT64, zoom_max INT64, geom_column_name STRING, zoom_min_column STRING, zoom_max_column STRING, max_tile_size_kb INT64, tile_feature_order STRING, drop_duplicates BOOL, extra_metadata STRING>|NULL
containing the different options. Valid options are described in the table below.
warning
If a query is passed in input
, it might be evaluated multiple times to generate the tileset. Thus, non-deterministic functions, such as ROW_NUMBER
should be avoided. If such a function is needed, the query should be saved into a table first and then passed as input
, to avoid inconsistent results.
name
description
legend
zoom_min
Default: 0
for POINTS
datasets and 2
for POLYGON/LINESTRING
datasets. A NUMBER
that defines the minimum zoom level for tiles. Any zoom level under this level won't be generated.
zoom_max
Default: 12
. A NUMBER
that defines the maximum zoom level for tiles. Any zoom level over this level won't be generated.
geom_column_name
Default: "geom"
. A STRING
that contains the name of the geography column that will be used. It must be of type GEOGRAPHY
.
zoom_min_column
Default: NULL
. It is the column that each row could have to modify its starting zoom. It can be NULL (then zoom_min
will be used). It must be a positive number between zoom_min
and zoom_max
.
zoom_max_column
Default: NULL
. It is the column that each row could have to modify its end zoom level. It can be NULL (then zoom_max
will be used). It must be a positive number between zoom_min
and zoom_max
.
max_tile_size_kb
Default: 512
. Maximum allowed: 6144
. A NUMBER
setting the approximate maximum size for a tile in kilobytes. For every zoom level, a consistent fraction of features will be dropped in every tile to make sure all generated tiles are below this maximum.
tile_feature_order
Default: NULL
. A STRING
defining the order in which properties are added to a tile. This expects the SQL ORDER BY
keyword definition, such as "aggregated_total DESC"
, the "ORDER BY"
part isn't necessary. Note that in aggregation tilesets you can only use columns defined as properties, but in simple feature tilesets you can use any source column no matter if it's included in the tile as property or not. This is an expensive operation, so it's recommended to only use it when necessary. If no order is provided, a custom dropping depending on the geometry type is performed. In case of POINT
geometries, features are dropped randomly. In case of POLYGON
geometries the features are added ordered by their area, while for LINESTRING
geometries the criteria is the feature length.
drop_duplicates
Default: false
. A BOOLEAN
to drop duplicate features in a tile. This will drop only exact matches (both the geometry and the properties are exactly equal). As this requires sorting the properties, which is expensive, it should only be used when necessary.
extra_metadata
Default: {}. A JSON object to specify the custom metadata of the tileset.
tip
Any option left as NULL
will take its default value. This also applies for geometry type dependant options such as zoom_min
or tile_feature_order
.
tip
A fraction_dropped_per_zoom
property will be included in the TileJSON, containing an estimate of the percentage of the features that have been dropped per zoom level as a result of applying the drop_fraction_as_needed
strategy. Please bear in mind that the exact percentages can be up to 5% higher.
warning
It should be taken into account that CREATE_TILESET
will not be executed for any level that reaches more than 10 millions tiles. This threshold is set in order to avoid some BigQuery limitations. This could occur if the input dataset is very sparse or zoom_max
is quite large.
warning
There are some cases where capacity pricing is the only option to create a tileset. Some tables containing huge geographies might trigger a Query exceeded resource limits error because of the high CPU usage.
Examples
If any of the options introduced above are required, the remaining fields should also be provided or set to NULL
. Here is an example of a valid structure for the options
parameter (the field alias can be ignored):
warning
In case of input
is set as a query, it should be taken into account that CTEs are not allowed. Also, the query should be as simple as possible in order to avoid BigQuery limitations about the complexity of the final query.
Additional examples
CREATE_POINT_AGGREGATION_TILESET
Description
Generates a point aggregation tileset.
input
:STRING
that can either be a quoted qualified table name (e.g.project-id.dataset-id.table-name
) or a full query wrapped in parentheses (e.g.(Select * FROM `project-id.dataset-id.table-name`)
).output_table
: Where the resulting table will be stored. It must be aSTRING
of the formproject-id.dataset-id.table-name
. Theproject-id
can be omitted (in which case the default one will be used). The dataset must exist and the caller needs to have permissions to create a new table on it. The process will fail if the target table already exists.options
:STRING
containing a valid JSON with the different options. Valid options are described the table below.
warning
If a query is passed in input
, it might be evaluated multiple times to generate the tileset. Thus, non-deterministic functions, such as ROW_NUMBER
should be avoided. If such a function is needed, the query should be saved into a table first and then passed as input
, to avoid inconsistent results.
geom_column
Default: "geom"
. A STRING
that marks the name of the geography column that will be used. It must be of type GEOGRAPHY
.
zoom_min
Default: 0
. A NUMBER
that defines the minimum zoom level for tiles. Any zoom level under this level won't be generated.
zoom_max
Default: 12
. A NUMBER
that defines the maximum zoom level for tiles. Any zoom level over this level won't be generated.
zoom_min_column
Default: NULL
. It is the column that each row could have to modify its starting zoom. It can be NULL (then zoom_min
will be used). When provided, if its value is greater than zoom_min
, it will take precedence and be used as the actual minimum.
zoom_max_column
Default: NULL
. It is the column that each row could have to modify its end zoom level. It can be NULL (then zoom_max will be used). When provided, if its value is lower than zoom_max
, it will be taken as the real maximum zoom level.
target_partitions
target_tilestats
Number: MIN, MAX, AVG, SUM and quantiles (from 3 to 20 breaks).
String / Boolean: List of the top 10 most common values and their count.
For aggregation tilesets, these statistics refer to the cells at the maximum zoom generated.
tile_extent
Default: 4096
. A NUMBER
defining the extent of the tile in integer coordinates as defined by the MVT spec.
tile_buffer
Default: 0
(disabled). A NUMBER
defining the additional buffer added around the tiles in extent units, which is useful to facilitate geometry stitching across tiles in the renderers. In aggregation tilesets, this property is currently not available and always 0
as no geometries go across tile boundaries.
max_tile_size_kb
Default: 1024
* 4 = 4096
@ tile_resolution
of 1
. Maximum allowed: 6144
. A NUMBER
specifying the approximate maximum size for a tile in kilobytes.
max_tile_size_strategy
Default: "throw_error"
. A STRING
that determines what to do when the maximum size of a tile is reached while it is still processing data. There are three options available:
"throw_error"
: The process will throw an error cancelling the aggregation, so no tiles or table will be generated."drop_fraction_as_needed"
: For every zoom level, this process will drop a consistent fraction of features in every tile to make sure all generated tiles are below the maximum size set inmax_tile_size_kb.
This could lead to features disappearing at different zoom levels. Features will be dropped according to thetile_feature_order
parameter, which becomes mandatory when using this strategy.
max_tile_features
Default: 0
(disabled). A NUMBER
that sets the maximum number of features a tile might contain. This limit is applied before max_tile_size_kb
, i.e., the tiler will first drop as many features as needed to keep this amount, and then continue with the size limits (if required). To configure in which order features are kept, use in conjunction with tile_feature_order
. The provided value scales by max_tile_features * 4 * tile_resolution^2
. See section below.
tile_feature_order
Default: ""
(disabled). A STRING
defining the order in which properties are added to a tile. This expects the SQL ORDER BY keyword definition, such as "aggregated_total DESC", the "ORDER BY" part isn't necessary. Note that in aggregation tilesets you can only use columns defined as properties, but in simple feature tilesets you can use any source column no matter if it's included in the tile as property or not. This is an expensive operation, so it's recommended to only use it when necessary.
aggregation_type
aggregation_resolution
Default: 6 + 1 => 7
@ tile_resolution
of 1
. A NUMBER
that specifies the resolution of the spatial aggregation.
For quadgrid the aggregation for zoom z
is done at z + resolution level
. For example, with resolution 6
, the z0
tile will be divided into cells that match the z6
tiles, or the cells contained in the z10
tile will be the boundaries of the z16
tiles within them. In other words, each tile is subdivided into 4^resolution
cells.
Note that adding more granularity necessarily means heavier tiles which take longer to be transmitted and processed in the final client, and you are more likely to hit the internal memory limits.
aggregation_placement
Default: "cell-centroid"
. A STRING
that defines what type of geometry will be used for the cells generated in the aggregation. For a quadgrid aggregation, there are currently four options:
"cell-centroid"
: Each feature will be defined as the centroid of the cell, that is, all points that are aggregated together into the cell will be represented in the tile by a single point."cell"
: Each feature will be defined as the whole cell, thus the final representation in the tile will be a polygon. This gives more precise coordinates but takes more space in the tile and requires more CPU to process it in the renderer."features-any"
: The point representing a feature will be any random point from the source data, that is, if 10 points fall inside a cell it will use the location of one of them to represent the cell itself"features-centroid"
: The feature will be defined as the centroid (point) of the points that fall into the cell. Note that this only takes into account the points aggregated under a cell, and not the cell shape (as "cell-centroid" does).
metadata
properties
tile_resolution
Default: 1
. A FLOAT
which determines final tile resolution. Valid values are 0.25, 0.5, 1, 2 and 4 which corrospond to tile sizes of 256px, 512px, 1024px, 2048px and 4096px respectively.
warning
There are some cases where capacity pricing is the only option to create a tileset. Some tables containing huge geographies might trigger a Query exceeded resource limits error because of the high CPU usage.
In web map tilesets, each additional zoom level has 4 times the amount of tiles as the previous zoom. Level 0 has 1 tile, level 1 has 4, level 2 has 16, etc.
For the map viewer, tile_resolution
is really a way of using an offset zoom level to load 'large' but few tiles , or 'small' but many tiles. For example, at zoom level 2 we might have to load 16 tiles to fill our screen. By increasing tile_resolution
one step (eg. 0.5
to 1
), we artificially use one z-level less (zoom level of 1) to load 4 (larger) tiles. Or we could increase tile_resolution
two steps (eg. from 0.5 to 2), to artificially use two z-levels less (zoom level of 0) and thus load just one (even larger) tile. Here is a table which illustrates the real requested Z levels based on a tileset's tile_resolution
.
1
2
1
0
0
0
2
3
2
1
0
0
3
4
3
2
1
0
4
5
4
3
2
1
As shown, tile_resolution
of 0.5
is where the tileset zoom level and map zoom levels match, so we use 0.5
as our baseline even though the default tile_resolution
is 1
. Other tile_resolution
values (eg, 1, 2, 4) will use offset z-levels when loaded on the map.
Relationship between tile\_resolution
and max\_tile\_features
/max\_tile\_size\_kb
tile\_resolution
and max\_tile\_features
/max\_tile\_size\_kb
In the web map viewer, tile_resolution
is really a way of using an offset zoom level to load 'larger' but less tiles. For example, at zoom level 3 we might have to load 16 tiles to fill our screen. By increasing tile_resolution
one step (eg. 1
to 2
), we artificially use one z-level less (zoom level of 2) to load 4 (larger) tiles. Or we could increase tile_resolution
two steps (eg. from 1 to 4), we artificially use two z-levels less (zoom level of 1) to load just one (even larger) tile. Here is a table which illustrates the real requested Z levels based on a tilesets tile_resolution
.
1
2
1
0
0
0
2
3
2
1
0
0
3
4
3
2
1
0
4
5
4
3
2
1
As shown, tile_resolution
of 0.5
is where the tileset zoom level and map zoom levels match. Other tile_resolution
values will need offset z-levels.
At the default tile_resolution
of 1
, any value set for max_tile_features
or max_tile_size_kb
will be multiplied by 4. For example, at tile_resolution
of 1
, a specified value for max_tile_features
of 10000 x 4 = 40000. This factor increases to 16 for tile_resolution
of 2
and 64 for tile_resolution
of 4
. Likewise, it decreases to 1 (ie. no change) at tile_resolution
0.5, and 0.25 at tile_resolution
of 0.25
(ie. divide by 4).
Although this is somewhat unintuitive, the offset ensures that tilesets generated using the same options (but different tile_resolutions) will always appear the same on the map.
Examples
Here is an example of valid properties
for a Point Aggregation Tileset:
In the example above, for all features we would get a property "new_column_name"
with the number of points that fall in it, the "most_common_ethnicity"
of those rows and whether there are points whose ethnicity value matches one specific value ("has_other_ethnicities"
). In addition to this, when there is only one point that belongs to this property (and only in that case) we will also get the column values from the source data: "name"
and "address"
.
Additional examples
CREATE_SPATIAL_INDEX_TILESET
Description
Creates a tileset that uses a spatial index (H3 and QUADBIN are currently supported), aggregating data from an input table that uses that same spatial index.
Aggregated data is computed for all levels between resolution_min
and resolution_max
. For each resolution level, all tiles for the area covered by the source table are added, with data aggregated at level resolution + aggregation resolution
.
input
:STRING
that can either be a quoted qualified table name (e.g.`project-id.dataset-id.table-name`
) or a full query contained by parentheses (e.g.(SELECT * FROM `project-id.dataset-id.table-name`)
).output_table
: Where the resulting table will be stored. It must be aSTRING
of the form`project-id.dataset-id.table-name`
. Theproject-id
can be omitted (in which case the default one will be used). The dataset must exist and the caller needs to have permissions to create a new table on it. The process will fail if the target table already exists.options
:STRING
containing a valid JSON with the different options. Valid options are described the table below.
warning
If a query is passed in input
, it might be evaluated multiple times to generate the tileset. Thus, non-deterministic functions, such as ROW_NUMBER
should be avoided. If such a function is needed, the query should be saved into a table first and then passed as input
, to avoid inconsistent results.
resolution_min
Default: 0
. A NUMBER
that defines the minimum resolution level for tiles. Any resolution level under this level won't be generated.
resolution_max
Default: 12
for QUADBIN tilesets, 6
for H3 tilesets. A NUMBER
that defines the maximum resolution level for tiles. Any resolution level over this level won't be generated.
spatial_index_column
A STRING
in the format spatial_index_type:column_name
, with spatial_index_type
being the type of spatial index used in the input table (can be quadbin
or h3
), and column_name
being the name of the column in that input table that contains the tile ids. Notice that the spatial index name is case-sensitive. The type of spatial index also defines the type used in the output table, which will be QUADBIN (for spatial index type quadbin
) or H3 (for spatial index type h3
).
resolution
A NUMBER
defining the resolution of the tiles in the input table.
aggregation_resolution
Defaults: 6
for QUADBIN tilesets, 4
for H3 tilesets. A NUMBER
defining the resolution to use when aggregating data at each resolution level. For a given resolution
, data is aggregated at resolution_level + aggregation resolution
.
properties
A JSON object containing the aggregated properties to add to each tile in the output table. It cannot be empty, since at least one property is needed for aggregating the original values
metadata
tile_resolution
Default: 1
. A FLOAT
which determines final tile resolution. Valid values are 0.25, 0.5, 1, 2 and 4 which corrospond to tile sizes of 256px, 512px, 1024px, 2048px and 4096px respectively.
tip
Any option left as NULL
will take its default value if available.
warning
There are some cases where capacity pricing is the only option to create a tileset. Some tables containing huge geographies might trigger a Query exceeded resource limits error because of the high CPU usage.
Examples
warning
In case of input
being set as a query, it should be taken into account that CTEs are not allowed. Also, the query should be as simple as possible in order to avoid BigQuery limitations about the complexity of the final query.
Additional examples
CREATE_SIMPLE_TILESET
warning
CREATE_TILESET
is capable of finding the right configuration for your input data, whereas this procedure requires you to set them yourself. Please use this procedure only if you need a really specific configuration for your tileset or need to tweak a particular option that it's not available in CREATE_TILESET
.
Description
Generates a simple tileset.
input
:STRING
that can either be a quoted qualified table name (e.g.`project-id.dataset-id.table-name`
) or a full query contained by parentheses (e.g.(SELECT * FROM `project-id.dataset-id.table-name`)
).output_table
: Where the resulting table will be stored. It must be aSTRING
of the form`projectI-id.dataset-id.table-name`
. Theproject-id
can be omitted (in which case the default one will be used). The dataset must exist and the caller needs to have permissions to create a new table on it. The process will fail if the target table already exists.options
:STRING
containing a valid JSON with the different options. Valid options are described the table below.
tip
To avoid issues in the process when building the queries that will be executed internally against BigQuery, it is highly recommended to use raw strings when passing long queries in the input
that might contain special characters.
warning
If a query is passed in input
, it might be evaluated multiple times to generate the tileset. Thus, non-deterministic functions, such as ROW_NUMBER
should be avoided. If such a function is needed, the query should be saved into a table first and then passed as input
, to avoid inconsistent results.
geom_column
Default: "geom"
. A STRING
that marks the name of the geography column that will be used. It must be of type GEOGRAPHY
.
zoom_min
Default: 0
. A NUMBER
that defines the minimum zoom level for tiles. Any zoom level under this level won't be generated.
zoom_max
Default: 12
. A NUMBER
that defines the maximum zoom level for tiles. Any zoom level over this level won't be generated.
zoom_min_column
Default: NULL
. It is the column that each row could have to modify its starting zoom. It can be NULL (then zoom_min will be used). When provided, if its value is greater than zoom_min
, it will take precedence and be used as the actual minimum.
zoom_max_column
Default: NULL
. It is the column that each row could have to modify its end zoom level. It can be NULL (then zoom_max will be used). When provided, if its value is lower than zoom_max
, it will be taken as the real maximum zoom level.
target_partitions
target_tilestats
Number: MIN, MAX, AVG, SUM and quantiles (from 3 to 20 breaks).
String / Boolean: List of the top 10 most common values and their count.
In Simple Tilesets, these statistics are based on the source data.
tile_extent
tile_buffer
Default: 16
. A NUMBER
defining the additional buffer added around the tiles in extent units, which is useful to facilitate geometry stitching across tiles in the renderers.
max_tile_size_kb
Default: 1024
* 4 = 4096
@ tile_resolution
of 1
. Maximum allowed: 6144
. A NUMBER
specifying the approximate maximum size for a tile in kilobytes.
max_tile_size_strategy
Default: "throw_error"
. A STRING
that determines what to do when the maximum size of a tile is reached while it is still processing data. There are three options available:
"throw_error"
: The process will throw an error cancelling the aggregation, so no tiles or table will be generated."drop_fraction_as_needed"
: For every zoom level, this process will drop a consistent fraction of features in every tile to make sure all generated tiles are below the maximum size set inmax_tile_size_kb.
This could lead to features disappearing at different zoom levels. Features will be dropped according to thetile_feature_order
parameter, which becomes mandatory when using this strategy.
max_tile_features
Default: 0
(disabled). A NUMBER
that sets the maximum number of features a tile might contain. This limit is applied before max_tile_size_kb
, i.e., the tiler will first drop as many features as needed to keep this amount, and then continue with the size limits (if required). To configure in which order features are kept, use in conjunction with tile_feature_order
. The provided value scales by max_tile_features * 4 * tile_resolution^2
. See section below.
tile_feature_order
Default: ""
(disabled). A STRING
defining the order in which properties are added to a tile. This expects the SQL ORDER BY
keyword definition, such as "aggregated_total DESC"
, the "ORDER BY"
part isn't necessary. Note that in aggregation tilesets you can only use columns defined as properties, but in simple feature tilesets you can use any source column no matter if it's included in the tile as property or not. This is an expensive operation, so it's recommended to only use it when necessary.
drop_duplicates
Default: false
. A BOOLEAN
to drop duplicate features in a tile. This will drop only exact matches (both the geometry and the properties are exactly equal). As this requires sorting the properties, which is expensive, it should only be used when necessary.
generate_feature_id
metadata
properties
Default: {}
. A JSON object that defines the extra properties that will be included associated to each cell feature. Each property is defined by its name and type (Number, Boolean or String). Check out the examples included below.
calculate_geoids
Default: false
. Generates an additional geoids
column that contains the geoid
value from each row in the input data that intersects with the tile. The input table must have a column named geoid
. This option is required to use the resulting tileset as a boundary.
tile_resolution
Default: 1
. A FLOAT
which determines final tile resolution. Valid values are 0.25, 0.5, 1, 2 and 4 which corrospond to tile sizes of 256px, 512px, 1024px, 2048px and 4096px respectively.
tip
If drop_fraction_as_needed
is used, a fraction_dropped_per_zoom
property will be included in the TileJSON, containing an estimate of the percentage of the features that have been dropped per zoom level. Please bear in mind that the exact percentages can be up to 5% higher.
warning
There are some cases where capacity pricing is the only option to create a tileset. Some tables containing huge geographies might trigger a Query exceeded resource limits error because of the high CPU usage.
In web map tilesets, each additional zoom level has 4 times the amount of tiles as the previous zoom. Level 0 has 1 tile, level 1 has 4, level 2 has 16, etc.
For the map viewer, tile_resolution
is really a way of using an offset zoom level to load 'large' but few tiles , or 'small' but many tiles. For example, at zoom level 2 we might have to load 16 tiles to fill our screen. By increasing tile_resolution
one step (eg. 0.5
to 1
), we artificially use one z-level less (zoom level of 1) to load 4 (larger) tiles. Or we could increase tile_resolution
two steps (eg. from 0.5 to 2), to artificially use two z-levels less (zoom level of 0) and thus load just one (even larger) tile. Here is a table which illustrates the real requested Z levels based on a tileset's tile_resolution
.
1
2
1
0
0
0
2
3
2
1
0
0
3
4
3
2
1
0
4
5
4
3
2
1
As shown, tile_resolution
of 0.5
is where the tileset zoom level and map zoom levels match, so we use 0.5
as our baseline even though the default tile_resolution
is 1
. Other tile_resolution
values (eg, 1, 2, 4) will use offset z-levels when loaded on the map.
Relationship between tile\_resolution
and max\_tile\_features
/max\_tile\_size\_kb
tile\_resolution
and max\_tile\_features
/max\_tile\_size\_kb
In the web map viewer, tile_resolution
is really a way of using an offset zoom level to load 'larger' but less tiles. For example, at zoom level 3 we might have to load 16 tiles to fill our screen. By increasing tile_resolution
one step (eg. 1
to 2
), we artificially use one z-level less (zoom level of 2) to load 4 (larger) tiles. Or we could increase tile_resolution
two steps (eg. from 1 to 4), we artificially use two z-levels less (zoom level of 1) to load just one (even larger) tile. Here is a table which illustrates the real requested Z levels based on a tilesets tile_resolution
.
1
2
1
0
0
0
2
3
2
1
0
0
3
4
3
2
1
0
4
5
4
3
2
1
As shown, tile_resolution
of 0.5
is where the tileset zoom level and map zoom levels match. Other tile_resolution
values will need offset z-levels.
At the default tile_resolution
of 1
, any value set for max_tile_features
or max_tile_size_kb
will be multiplied by 4. For example, at tile_resolution
of 1
, a specified value for max_tile_features
of 10000 x 4 = 40000. This factor increases to 16 for tile_resolution
of 2
and 64 for tile_resolution
of 4
. Likewise, it decreases to 1 (ie. no change) at tile_resolution
0.5, and 0.25 at tile_resolution
of 0.25
(ie. divide by 4).
Although this is somewhat unintuitive, the offset ensures that tilesets generated using the same options (but different tile_resolutions) will always appear the same on the map.
Examples
In Simple Tilesets, the properties
are defined by the source data itself. You only have to write the name of the column (as defined in the source query or table) and its type. It doesn't support any extra transformations or formulae since those can be applied to the source query directly.
Here is an example of a valid JSON for the options
parameter:
Additional examples
Last updated