Tilesets API recipe reference

Current version: 1

Tileset recipes are tile transformation documents that tell the Tilesets API how to turn tileset source data into vector tiles. Recipes must be constructed according to the rules in this recipe reference.

A recipe is a JSON object that must contain the following top-level fields:

{
  "version": 1,
  "layers": { ... }
}

A layer object is the primary way of describing how a vector tile layer should be created. It specifies where to retrieve source data, the precision of the data through zoom levels, and how to transform features and render them into tiles. The following fields are the top-level options for a single layer:

You can further refine the resulting tileset with the following optional fields:

The following describes every available field for a LayerObject and the JSON type that field must be.

{
  "minzoom": Integer,
  "maxzoom": Integer,
  "features": {
    "id": {
      "attribute_id": String,
      "add_to_attributes": String,
      "output_id": Boolean
    },
    "attributes": {
      "zoom_element": Array,
      "set": Object,
      "allowed_output": Array
    },
    "filter": Object,
    "simplification": Number or Array
  },
  "tiles": {
    "extent": Integer,
    "buffer_size": Integer,
    "limit": Array,
    "union": [
      {
        "group_by": Array,
        "aggregate": Array,
        "maintain_direction": Boolean,
        "where": Array
      }
    ]
  }
}

The simplest example tileset recipe includes a layer name, a tileset source ID, a minimum zoom value, and a maximum zoom.

{
  "version": 1,
  "layers": {
    "trees": {
      "source": "mapbox://tileset-source/{username}/trees-data",
      "minzoom": 4,
      "maxzoom": 8
    }
  }
}

Recipes can also be arrays of recipe objects. This format can be used to create multi-layer tilesets. Recipes can have a maximum of 20 layers defined.

{
  "version": 1,
  "layers": {
    "trees": { ... },
    "parks": { ... },
    "paths": { ... }
  }
}

The layer name key is required for each LayerObject (e.g. "trees", "parks", and "paths" in the above example). This is the unique identifier for the layer of data in your final tileset. For any map each layer name must be unique. The layer name must be a string with only underscores (_) and alphanumeric characters.

A source refers to a tileset source, which is a collection of geographic data stored as line-delimited GeoJSON on Mapbox.com. Tileset sources can be created via the Create a tileset source endpoint of the Tilesets API.

The minzoom and maxzoom configurations control the zoom levels at which your data will be tiled. They are required for a recipe. These values must be integers. The minzoom must be less than or equal to maxzoom, and both must be between the values of 0 and 16.

Zoom levels play a large role in your output tileset. The higher the zoom level, the higher fidelity your data is as users zoom in. This also comes at a cost. Increasing zoom level fidelity creates exponentially more tiles!

It’s important to consider the cases your map is trying to solve when choosing zoom levels. If your users are going to be viewing the map at a global extent it’s not necessary to choose a high zoom. If your users are going to be viewing the map at a city or street level, high zooms will be helpful for the most accurate data.

If you know the precision to which you want your data to be represented, this table shows the approximate precision corresponding to various minzoom and maxzoom choices:

The features configuration object is used to describe how features are individually processed into vector tiles. This field contains the following elements, which are evaluated in the order of the list provided below:

The id configuration gives you control over what field is used as the feature ID during tiling. It also allows you to specify where to put this ID in the resulting tileset as an attribute.

The following fields are allowed in the id object:

In this example, the recipe indicates that the iso_2 property in each feature should be the feature ID in the resulting tileset:

{
  "features": {
    "id": {
      "attribute_id": "iso_2"
    }
  }
}

In this example, the recipe saves the top-level ID field in the attribute road_id of the final vector tile. This is particularly helpful for saving top-level string IDs that will otherwise be converted to integers in the final vector tile.

{
  "features": {
    "id": {
      "add_to_attributes": "road_id"
    }
  }
}

If output_id is true, the ID is saved to the id field within a feature of a vector tile. The current Mapbox Vector Tile Specification does not allow for string-based IDs in features, so if this value is true any string IDs will be converted to an integer using a hash.

In this example, the recipe adds feature IDs to feature attributes using the attribute my_id, but does not place the ID in the final vector tile ID field.

{
  "features": {
    "id": {
      "add_to_attributes": "my_id",
      "output_id": false
    }
  }
}

The filter configuration is a single filter expression that results in a true or false evaluation for each feature as configured by the minzoom and maxzoom. This is the primary way to control which features are allowed into the final tileset on a per-feature basis. If no filter is provided, by default this results in a value of true for all features.

Filter expressions

In various configurations throughout the recipe, you have the ability to select relevant features by their attributes. This is possible with filter expressions, which use the Mapbox GL JS expression syntax defined in the Mapbox GL JS Style Spec.

Each filter is a JSON array that is evaluated for a boolean or value result using the following operations:

• Type assertion:

  • array, boolean, number, object, string, typeof

• Type conversion:

  • to-boolean, to-number, to-string

• Quoting:

  • literal

• Feature characteristics:

  • geometry-type, id, zoom

• Data retrieval:

  • properties, at, get, has, length

• Comparison:

  • ==, !=, <, >, <=, >=, step

• Boolean operations

  • !, all, any

• Conditionals:

  • case, coalesce, match

• Local variables

  • let, var

• String manipulation

  • concat, downcase, upcase

• Arithmetic

  • -, +, /, *, ^, %, abs, ceil, floor, e, ln, ln2, log10, log2, max, min, round, sqrt

• Trigonometry

  • acos, asin, atan, cos, sin, tan, pi

The attributes configuration allows for manipulation of attribute data, generation of new attributes, and removal of attributes. The available options are described below, and implemented in the order they are listed:

For each attributes with a specified zoom_element, the final output attribute at zoom level N will be the Nth element in the array in the source data. If no zoom_element is defined, no attributes are altered. If the zoom level is greater than or equal to the number of elements in the array, the last element is used.

Consider the following attributes for a single GeoJSON feature:

{
  "type": "Feature",
  "geometry": { ... },
  "properties": { "name": [ null, null, "Main", "Main St.", "Main Street" ] }
}

In this example, the zoom_element array includes name. Using the attributes from the GeoJSON above, this feature would have no name attribute at zoom levels 0 and 1, would have "Main" at zoom level 2, "Main St." at zoom level 3, and "Main Street" at zoom levels 4 and above.

{
  "features": {
    "attributes": {
      "zoom_element": [ "name" ]
    }
  }
}

Consider the following attributes for a single GeoJSON feature:

{
  "type": "Feature",
  "geometry": { ... },
  "properties": { "place": "state", "name": "California" }
}

In this example, the set attribute defines a new attribute to be included in the final tileset, labelrank, that is derived from the existing data's place attribute. Using the "match" expression, it assigns a value to features based on the value of "place". If "place" is equal to "country", then the labelrank attribute for the resulting feature will have a value of 0, and so on. It also provides a default value of 5 for any features that have a "place" value that does not match any of the values explicitly provided.

{
  "features": {
    "attributes": {
      "set": {
        "labelrank": [
          "match", [ "get", "place" ],
          "country", 0,
          "state", 1,
          "region", 2, "province", 2,
          "district", 3, "county", 3,
          "municipality", 4, "city", 4,
          5
        ]
      }
    }
  }
}

If an allowed_output array is provided only the attributes specified in the array will be saved to the tileset. This does not prevent the attributes that are not excluded by allowed_output from being used in filter expressions and other steps throughout the publish job.

In this example, features in the resulting tileset will only have two attributes, name_en & name_es:

{
  "features": {
    "attributes": {
      "allowed_output": [ "name_en", "name_es" ]
    }
  }
}

The simplification expression or value describes the maximum distance that a point can be from the straight line that connects its two neighbors and still be considered to be on the line, and can therefore be removed safely. Any point with a distance that is larger than the simplification value is considered to be away from the line, and must be preserved.

As you increase the simplification value, the number of vertices in each feature decreases. The Tilesets API recipe validator will reject any simplification value that is more than 4096. If you do not add a value for simplification, the Tilesets API will use 4, the default value.

The resulting shape depends on the original shape of your feature. For instance, if your original feature is circular and you increase simplification, the result will look more like a polygon. If your original feature is a curved line and you increase simplification, the result will look more like a straight line.

The Tilesets API uses the Ramer–Douglas–Peucker algorithm to simplify features.

The simplification may be a constant number, or it may be an expression that evaluates to a number. A typical use for an expression for the simplification would be to use a minimal simplification at the layer's maximum zoom level, so it can be overzoomed with high precision, but to use a larger simplification at lower zoom levels that will never be magnified very far.

The tiles object contains the following elements, which are evaluated as each tile is being assembled from its component features:

buffer_size represents a percentage of the size of a tile. The default buffer size is 0.5. Note that the value of this attribute cannot be larger than 100.

Buffers are particularly helpful for label point layers to avoid cutting labels of at tile boundaries.

The default value is 500 KiB. The value cannot be larger than 500 or smaller than 1. Configuring layer_size can be helpful for improving rendering speed.

During tile creation it is possible for polygons to completely cover a tile and the area surrounding its buffer. These are called as "filled features". If all features within a tile are filled features, it may be useful for some tilesets to not create any tiles at all and expect that clients will look to higher zoom levels. To do this, you can use the remove_filled recipe.

The syntax utilizes a filter-expression to allow control over what features exactly should be removed.

"tiles": {
  "remove_filled": expression
}

No tile will be created if:

• All features within the tile are considered filled features
• All features are matched by the filter-expression provided in remove_filled

The following example removes all tiles that contain only filled features:

"tiles": {
  "remove_filled": true
}

The following example removes all tiles that contain only filled features after zoom level 5:

"tiles": {
  "remove_filled": [">", [ "zoom" ], 5]
}

The limit field must be an array of limitation rules, each of which is evaluated in sequence to potentially limit the total number of features to be included in the final tile.

Rules that limit the total number of features in a tile have one of following forms:

• [ "lowest_where", filter-expression , number , attribute ]
• [ "highest_where", filter-expression , number , attribute ]

Rules that limit the number of features within a specified distance have one of the following forms:

• [ "lowest_where_in_distance", filter-expression , number , attribute ]
• [ "highest_where_in_distance", filter-expression , number , attribute ]

The number is a divisor of the total tile area. So, for instance, if the number is 256, the features will be spaced such that 256 of them are spaced evenly across the tile. The features with the lowest or highest value of attribute within each cluster are prioritized.

The difference is that lowest_where and highest_where choose any number of features that match the filter-expression, even if these features are right on top of each other, while lowest_where_in_distance and highest_where_in_distance choose any number of features that match the filter-expression while still being acceptably spatially-separated.

You can order the sequence of features in the final output tile by a specified attribute. The attribute values must be comparable (all strings or all numbers).

This example orders the features by the sequence attribute:

"tiles": { "order": "sequence" }

Renderers, including Mapbox GL, draw or place features in the order they appear in the tile. LineString and Polygon features that are drawn early in the sequence may be covered by overlapping features that are drawn later in the sequence. Conversely, labels that are placed early in the sequence will prevent labels of features later in the sequence from being placed nearby.

You can follow these general guidelines:

• The most important LineStrings and Polygons should have the highest values for their order attribute, so they are not covered by overlapping features.
• The most important labels should have the lowest values for their order attribute, so they are placed first.

Read more about how label visibility is affected by the order of features in the Optimize map label placement guide.

If no order attribute is specified, the features will appear in an unpredictable order.

You can union features together if a specified set of their attributes match. The simplest case unions all features that have exactly the same attributes:

"tiles": { "union": [ { } ] }

The union specification object can contain an expression to union only features that match the specified expression as well as having matching attributes:

"where": expression

Expression options:

• group_by: [attribute, attribute, attribute] - Use group_by to union features that have specified attributes that match, instead of requiring all attributes to match.
• aggregate: { attribute: type, attribute: type } - Use aggregate to accumulate the specified attributes from the unioned features. Attributes that are not specified in either group_by or aggregate will be removed. Acceptable types of aggregation include sum (to add numbers), product (to multiply numbers), min (to choose the lowest number), max (to choose the highest number), mean (to take the average of numbers), comma (to concatenate with a comma), or concat (to concatenate the feature data without a delimiter).
• maintain_direction: boolean - Use maintain_direction: false to make more compact unions of LineStrings for which directionality doesn't matter. This is done by reversing some of the LineStrings if that helps to connect them.

For example, you could specify the following to union only features where highway=motorway, and retain the average of their speed_limit attributes:

"tiles": {
  "union":
  [
    {
      "where": [ "==", [ "get", "highway" ], "motorway" ],
      "maintain_direction": true,
      "aggregate": { "speed_limit": "mean" }
    }
  ]
}

This example uses maintain_direction: true (the default) because motorway roads are generally mapped as pairs of roadways whose direction indicates their one-way direction.

• For a list of example recipes that correspond to common tileset use-cases, see the Tileset recipe examples page.
• The Get started with the Tilesets API and CLI tutorial walks you through the process of creating a new tileset, including creating and using a tileset recipe, with the Tilesets CLI.
• The Tilesets API has several endpoints that can be used to validate, update, and read a tileset's recipe. Learn more in the Tilesets API documentation.