specify maximum buffer

[jfirebaugh]

[This is like https://github.com//issues/59, but getting at the actual implementation need in mapbox-gl.]

To ensure that implementations can make reasonable assumptions about the size of integers needed to store coordinate values for vector tiles of a given extent, the specification should place limits on how much buffering is permissible for a given extent.

Proposed change: in 4.1 replace

A layer MUST contain an extent that describes the width and height of the tile in integer coordinates. The geometries within the Vector Tile MAY extend past the bounds of the tile's area as defined by the extent. Geometries that extend past the tile's area as defined by extent are often used as a buffer for rendering features that overlap multiple adjacent tiles.

with

A layer MUST contain an extent that describes the width and height of the tile in integer coordinates. As a buffer for rendering features that overlap multiple adjacent tiles, the coordinates of geometries within the Vector Tile MAY extend past the bounds of the tile's area as defined by the extent, subject to the following limitations:

• A geometry MUST NOT have a coordinate value greater than (extent * 2) - 1
• A geometry MUST NOT have a coordinate value less than -extent

In other words, no more than one tile's worth of buffer is permitted.

cc @flippmoke @lucaswoj @springmeyer @ericfischer

[e-n-f]

I would prefer SHOULD NOT since there have been requests for an option (tippecanoe's --no-clipping and --no-duplication) that will keep large features together in a single tile for tile-reduce purposes rather than letting them be cut naturally into tiles.

[jfirebaugh]

SHOULD NOT would be fine with me.

[lucaswoj]

For context, GL JS has been having some issues due to Mapnik encoding coordinate values equal to extent * 2 (one greater than the proposed upper bound of (extent * 2) - 1).

Adopting this new specification will allow renderer implementations to make confident and efficient choices about the data type used to represent coordinates.

See mapbox/mapbox-gl-js#2568 for more information.

[pnorman]

👎 on MUST. I'm iffy on SHOULD NOT. I can understand the desire to know the maximum coordinate values from only parsing extent, but should something for an implementation detail like this be a SHOULD item? What are the requirements on an implementation encountering a valid vector tile with coordinates outside the proposed bounds?

[jfirebaugh]

should something for an implementation detail like this be a SHOULD item

The specification absolutely can and does define constraints that reflect reasonable practical needs of software that consumes vector tiles. The practical needs of consumers were what drove the v2 push for defining winding order, polygon validity, and such; this is in the same category.

What are the requirements on an implementation encountering a valid vector tile with coordinates outside the proposed bounds?

The specification doesn't list any error handling requirements for tiles that do not conform to MUST or SHOULD requirements, so it would be up the the implementation.

[pnorman]

Reading more on the expectations of MUST and SHOULD I'm wondering if this requirement needs to be MUST for interoperability reasons.