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

[Yuri Astrakhan]

Uglier is a relative term :))

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.

On Wed, Nov 13, 2019 at 9:59 AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

>
>
> On Nov 13, 2019, at 8:22 AM, Yuri Astrakhan <yuriastrakhan at gmail.com>
> wrote:
>
> Paul, I was thinking of using the same definitions as in ST_AsMVTGeom():
>
> * buffer is the buffer distance in tile coordinate space to optionally
> clip geometries.
>
> So the buffer would be in the tile's units, and depend on the zoom level.
> I suspect we have to add extent parameter too, rather than use default
> 4096.
>
>
> Yeah, that’s what I thought… it gets uglier and uglier, no?
>
>
>
>
> On Wed, Nov 13, 2019 at 9:14 AM Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
>
>> 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
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> 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/60bd3299/attachment.html>