I could be wrong, but I suspect this was a bug in Mapnik in that case. My understanding is that extent is how many units are in a single tile, i.e. a tile is 4096 x 4096 units. The buffer is the number of those units, so if a tile width is a whole world (along the equator), the formula would be equatorial_length / 4096 * buffer_size. For higher zooms, we would divide it by 2 ^ zoom.

I do not understand what dividing by pixel size would actually mean in this context.

Hi @nyurik
as I understood it, pixel_width is actually taken from tileset.pixel_scale in https://github.com/openmaptiles/openmaptiles-tools/blob/master/openmaptiles/sqltomvt.py#L31 Then you get a ratio of buffer_size/pixel_scale which in the case of layer_place where the buffer_size=256 ends up in 256/256 and thats why the buffer of tile is equal to tile size in Mapnik.
I can't say whether it is bug in Mapnik or not however I think that for layer_place you want to have a big buffer as Mapnik has due to labels. And if the calculation of buffer size is correct now in tile_to_bbox() function the only way how to fix it is to modify buffer size in all layer/tileset definitions.

@lazaa32 what are the units of measurements for the pixel_scale and buffer_size? I think the legacy tile is 256x256 pixels (raster), whereas the vector tile is (i guess) 4096x4096 (extent). If the measurement for buffer_size was in pixels, than yes - we need to convert 256 to be the width of a tile. I can't recall if we have 256 hardcoded anywhere.

@nyurik I think that pixel_scale and buffer_size are really in pixels by legacy.
On the other hand, right now we don't have any parameter that defines extent of vector tile. It is only hardcoded here: https://github.com/openmaptiles/openmaptiles-tools/blob/master/openmaptiles/sqltomvt.py#L25

We probably don't want to modify the buffer_size in yaml definitions as it makes huge buffer in case you render tiles old way with Mapnik and increases the size of tile.

please re-run make rebuild-expected and submit changes