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

Yuri Astrakhan yuriastrakhan at gmail.com
Wed Nov 13 11:29:38 PST 2019


Thanks, but per later email, it seems percentage growth in the target srid
should cover all such complexities, without the need to know tile extent.

Calling it margin sounds good to me.

On Wed, Nov 13, 2019, 13:24 <rmrodriguez at carto.com> wrote:

> On Wed, Nov 13, 2019 at 4:17 PM Yuri Astrakhan <yuriastrakhan at gmail.com>
> wrote:
>
> > My understanding is that for a complete tiles support one always has to
> deal with a common set of tile params --  z, x, y, extent, buffer, srid.
> Those define pretty much everything there is to define about most tiles I
> have seen. I agree that having two params rather than just one is less
> ideal, and I haven't seen anyone using non-4096 extent yet, but we already
> support it in make geom, so extent should be defaulted to 4096 for
> consistency. Buffer should default to 0 in makeTile, whereas in geometry
> existing 256 default seems reasonable.
>
> CARTO uses a configurable extent for MVTs, for example CartoVL uses
> 2048 but you can pass whatever you want to the map configuration and
> it'll deal with it nicely. We aren't using `ST_TileEnvelope` so I
> haven't paid much attention to it for now, and use ST_Expand over the
> tile bbox. The tricky thing is that the extra size added needs to
> depend both on the resolution (zoom level) and the buffersize and I'm
> not sure how to expose that without exposing too much about the
> implementation. I guess that something like accepting a number N and
> the function would expand the tile N * the tile resolution.
>
> To cover this case, I think it'd be better to have a
> `ST_TileResolution(z integer)` and you can do it yourself. Following
> your example:
> {{{
> ST_Expand(ST_TileEnvelope(x,y,z), ST_TileResolution(z) / :extent * :buffer)
> }}}
> Right?
>
> --
> Raúl Marín Rodríguez
> carto.com
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/9f06f800/attachment-0001.html>


More information about the postgis-devel mailing list