[postgis-devel] Proposal: Adding buffer parameter to ST_TileEnvelope()

[Paul Ramsey]

Buffer in what units?
Would you really buffer, say, a tile that is a quarter of the earth, by 100 meters? Buffering tiles is to make rendering work better, so the buffers will be relative to the expected widest applied style/marker.
If in “pixels”, what would be the expected number of pixels in a tile? In proportion of the tile? 1/10 of a tile? 1/20?
P.

> On Nov 13, 2019, at 12:06 AM, Yuri Astrakhan <yuriastrakhan at gmail.com> wrote:
> 
> Would it make sense to add a `buffer` parameter to ST_TileEnvelope(), similar to ST_AsMVTGeom() ? 
> 
> To my understanding, ST_TileEnvelope common use case is to create a bbox filter -- to get just the relevant data before packaging it with ST_AsMVT().  This works well for the line and polygon geometries, but when dealing with point data, e.g. city names, one has to increase that bbox by a significant margin (e.g. half of the tile size) in order to capture labels from the neighboring tiles and prevent label clipping.
> 
> I think this use case is common enough to add buffer parameter to ST_TileEnvelope - where it would increase the bbox size by the the given distance in tile coordinate space.
> 
> Proposed additional signature:
> 
> geometry ST_TileEnvelope(integer tileZoom, integer tileX, integer tileY, integer buffer=0, geometry bounds=...);
> 
> (Would existing method signature without the buffer param conflict if the buffer is added before the existing bounds param? They are of different type.)
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel