<div dir="ltr">Michael, thank you for your example. Per Paul's previous email, it made me realize that unlike ST_AsMVTGeom, ST_TileEnvelope does not need to understand the concept of extent (internal "pixels"), but instead can work just as well with percentages.<div><br></div><div>Updated proposal:   buffer is a percentage increase of the original tile, limited to SRID space.  E.g.  buffer=0.5 would grow the tile by 50%, but if zoom=0, it would not grow at all.  If the tile is on the edge (e.g. 0,0), growing it should extend the longitude across the anti-meridian line, but should not grow northwards (srid limit).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 13, 2019 at 10:42 AM Michael Davis <<a href="mailto:michael.davis@spatialkey.com">michael.davis@spatialkey.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>As a postgis user who is currently experimenting with using those functions I very much support having a buffer parameter.  At my company we're using MVT generated via code and looking to switch to using postgis' serialization instead.  We've definitely found having a buffer as absolutely critical to avoiding tile clipping issues.</div><div><br></div><div>Currently the SQL I'm using to buffer by 10% looks like this</div><div><font face="monospace">WHERE ST_Intersects(geom, ST_Expand(ST_Transform(ST_TileEnvelope(2,1,1), 4326), (ST_XMax(ST_Transform(ST_TileEnvelope(2,1,1), 4326)) - ST_XMin(ST_Transform(ST_TileEnvelope(2,1,1), 4326)))*.1 )) </font></div><div><br></div><div>Which is quite ugly and we'd probably end up just generating the box in our code instead to avoid that in a production solution.  Having a parameter to specify the buffer in ST_TileEnvelope would be a lot cleaner.</div><div><br></div><div>P.S. It's my first time posting to this list so apologies if it doesn't go through right. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 13, 2019 at 9:22 AM <<a href="mailto:postgis-devel-request@lists.osgeo.org" target="_blank">postgis-devel-request@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Date: Wed, 13 Nov 2019 01:06:20 -0500<br>
From: Yuri Astrakhan <<a href="mailto:yuriastrakhan@gmail.com" target="_blank">yuriastrakhan@gmail.com</a>><br>
To: PostGIS Development Discussion <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>><br>
Subject: [postgis-devel] Proposal: Adding buffer parameter to<br>
        ST_TileEnvelope()<br>
Message-ID:<br>
        <<a href="mailto:CAJGfNe8vDv5ghoGoa27ONognyiB2Oc-qHgt%2BbEx4W8nYDwYDAg@mail.gmail.com" target="_blank">CAJGfNe8vDv5ghoGoa27ONognyiB2Oc-qHgt+bEx4W8nYDwYDAg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Would it make sense to add a `buffer` parameter to ST_TileEnvelope(),<br>
similar to ST_AsMVTGeom() ?<br>
<br>
To my understanding, ST_TileEnvelope common use case is to create a bbox<br>
filter -- to get just the relevant data before packaging it with<br>
ST_AsMVT().  This works well for the line and polygon geometries, but when<br>
dealing with point data, e.g. city names, one has to increase that bbox by<br>
a significant margin (e.g. half of the tile size) in order to capture<br>
labels from the neighboring tiles and prevent label clipping.<br>
<br>
I think this use case is common enough to add buffer parameter to<br>
ST_TileEnvelope - where it would increase the bbox size by the the<br>
given distance in tile coordinate space.<br>
<br>
Proposed additional signature:<br>
<br>
geometry ST_TileEnvelope(integer tileZoom, integer tileX, integer tileY,<br>
integer buffer=0, geometry bounds=...);<br>
<br>
(Would existing method signature without the buffer param conflict if the<br>
buffer is added before the existing bounds param? They are of different<br>
type.)<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/f9bf6a64/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/f9bf6a64/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 13 Nov 2019 10:31:44 +0100<br>
From: "Felix Kunde" <<a href="mailto:felix-kunde@gmx.de" target="_blank">felix-kunde@gmx.de</a>><br>
To: <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
Cc: "PostGIS Development Discussion" <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>><br>
Subject: Re: [postgis-devel] Proposal: Adding buffer parameter to<br>
        ST_TileEnvelope()<br>
Message-ID:<br>
        <trinity-cab8aeed-70c6-4f55-9ac2-d3376020c4fd-1573637504554@3c-app-gmx-bs07><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/96dbc0fc/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/96dbc0fc/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 13 Nov 2019 09:10:15 -0500<br>
From: Yuri Astrakhan <<a href="mailto:yuriastrakhan@gmail.com" target="_blank">yuriastrakhan@gmail.com</a>><br>
To: PostGIS Development Discussion <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>><br>
Subject: Re: [postgis-devel] Proposal: Adding buffer parameter to<br>
        ST_TileEnvelope()<br>
Message-ID:<br>
        <CAJGfNe96vEctzH22Lz6jOET+2+i3E8Lg75+kLQHtU=<a href="mailto:M8of7CCQ@mail.gmail.com" target="_blank">M8of7CCQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Wrapping would look like this for srid=3857, and more complex for other<br>
srids (assuming my math is correct). I think having it as part of the<br>
ST_TileEnvelope will simplify this very common use case, avoid errors, and<br>
will run faster.<br>
<br>
ST_Expand(<br>
  ST_TileEnvelope(:zoom, :x, :y),<br>
  20037508.34 * 2 / (2 ^ :zoom) / :extent * :buffer<br>
)<br>
<br>
Both :extent and :buffer are defined in ST_AsMVTGeom().<br>
<br>
Note that the same argument could have been used for ST_TileEnvelope()<br>
itself -- it can be easily implemented with a short function. but it was<br>
implemented as a native PostGIS function because of how frequently it is<br>
used.<br>
<a href="https://github.com/mapbox/postgis-vt-util/blob/master/src/TileBBox.sql#L17" rel="noreferrer" target="_blank">https://github.com/mapbox/postgis-vt-util/blob/master/src/TileBBox.sql#L17</a><br>
<br>
<br>
On Wed, Nov 13, 2019 at 4:31 AM Felix Kunde <<a href="mailto:felix-kunde@gmx.de" target="_blank">felix-kunde@gmx.de</a>> wrote:<br>
<br>
> What speaks against ST_Expand(ST_TileEnvelope ... ?<br>
><br>
> *Gesendet:* Mittwoch, 13. November 2019 um 07:06 Uhr<br>
> *Von:* "Yuri Astrakhan" <<a href="mailto:yuriastrakhan@gmail.com" target="_blank">yuriastrakhan@gmail.com</a>><br>
> *An:* "PostGIS Development Discussion" <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>><br>
> *Betreff:* [postgis-devel] Proposal: Adding buffer parameter to<br>
> ST_TileEnvelope()<br>
> Would it make sense to add a `buffer` parameter to ST_TileEnvelope(),<br>
> similar to ST_AsMVTGeom() ?<br>
><br>
> To my understanding, ST_TileEnvelope common use case is to create a bbox<br>
> filter -- to get just the relevant data before packaging it with<br>
> ST_AsMVT().  This works well for the line and polygon geometries, but when<br>
> dealing with point data, e.g. city names, one has to increase that bbox by<br>
> a significant margin (e.g. half of the tile size) in order to capture<br>
> labels from the neighboring tiles and prevent label clipping.<br>
><br>
> I think this use case is common enough to add buffer parameter to<br>
> ST_TileEnvelope - where it would increase the bbox size by the the<br>
> given distance in tile coordinate space.<br>
><br>
> Proposed additional signature:<br>
><br>
> geometry ST_TileEnvelope(integer tileZoom, integer tileX, integer tileY,<br>
> integer buffer=0, geometry bounds=...);<br>
><br>
> (Would existing method signature without the buffer param conflict if the<br>
> buffer is added before the existing bounds param? They are of different<br>
> type.)<br>
> _______________________________________________ postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/a2da691e/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/a2da691e/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 13 Nov 2019 08:14:42 -0600<br>
From: Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>><br>
To: PostGIS Development Discussion <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>><br>
Subject: Re: [postgis-devel] Proposal: Adding buffer parameter to<br>
        ST_TileEnvelope()<br>
Message-ID: <<a href="mailto:75FEEE10-D876-4FE4-AB87-A09DE6396157@cleverelephant.ca" target="_blank">75FEEE10-D876-4FE4-AB87-A09DE6396157@cleverelephant.ca</a>><br>
Content-Type: text/plain;       charset=utf-8<br>
<br>
Buffer in what units?<br>
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.<br>
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?<br>
P.<br>
<br>
> On Nov 13, 2019, at 12:06 AM, Yuri Astrakhan <<a href="mailto:yuriastrakhan@gmail.com" target="_blank">yuriastrakhan@gmail.com</a>> wrote:<br>
> <br>
> Would it make sense to add a `buffer` parameter to ST_TileEnvelope(), similar to ST_AsMVTGeom() ? <br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> Proposed additional signature:<br>
> <br>
> geometry ST_TileEnvelope(integer tileZoom, integer tileX, integer tileY, integer buffer=0, geometry bounds=...);<br>
> <br>
> (Would existing method signature without the buffer param conflict if the buffer is added before the existing bounds param? They are of different type.)<br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 13 Nov 2019 09:22:01 -0500<br>
From: Yuri Astrakhan <<a href="mailto:yuriastrakhan@gmail.com" target="_blank">yuriastrakhan@gmail.com</a>><br>
To: PostGIS Development Discussion <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>><br>
Subject: Re: [postgis-devel] Proposal: Adding buffer parameter to<br>
        ST_TileEnvelope()<br>
Message-ID:<br>
        <<a href="mailto:CAJGfNe-%2Bk1wSM2poazmTABhEFZTD24G3expA4FsZDCqP6bD5oA@mail.gmail.com" target="_blank">CAJGfNe-+k1wSM2poazmTABhEFZTD24G3expA4FsZDCqP6bD5oA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Paul, I was thinking of using the same definitions as in ST_AsMVTGeom():<br>
<br>
* buffer is the buffer distance in tile coordinate space to optionally clip<br>
geometries.<br>
<br>
So the buffer would be in the tile's units, and depend on the zoom level.<br>
I suspect we have to add extent parameter too, rather than use default 4096.<br>
<br>
<br>
On Wed, Nov 13, 2019 at 9:14 AM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>><br>
wrote:<br>
<br>
> Buffer in what units?<br>
> Would you really buffer, say, a tile that is a quarter of the earth, by<br>
> 100 meters? Buffering tiles is to make rendering work better, so the<br>
> buffers will be relative to the expected widest applied style/marker.<br>
> If in “pixels”, what would be the expected number of pixels in a tile? In<br>
> proportion of the tile? 1/10 of a tile? 1/20?<br>
> P.<br>
><br>
> > On Nov 13, 2019, at 12:06 AM, Yuri Astrakhan <<a href="mailto:yuriastrakhan@gmail.com" target="_blank">yuriastrakhan@gmail.com</a>><br>
> wrote:<br>
> ><br>
> > Would it make sense to add a `buffer` parameter to ST_TileEnvelope(),<br>
> similar to ST_AsMVTGeom() ?<br>
> ><br>
> > To my understanding, ST_TileEnvelope common use case is to create a bbox<br>
> filter -- to get just the relevant data before packaging it with<br>
> ST_AsMVT().  This works well for the line and polygon geometries, but when<br>
> dealing with point data, e.g. city names, one has to increase that bbox by<br>
> a significant margin (e.g. half of the tile size) in order to capture<br>
> labels from the neighboring tiles and prevent label clipping.<br>
> ><br>
> > I think this use case is common enough to add buffer parameter to<br>
> ST_TileEnvelope - where it would increase the bbox size by the the given<br>
> distance in tile coordinate space.<br>
> ><br>
> > Proposed additional signature:<br>
> ><br>
> > geometry ST_TileEnvelope(integer tileZoom, integer tileX, integer tileY,<br>
> integer buffer=0, geometry bounds=...);<br>
> ><br>
> > (Would existing method signature without the buffer param conflict if<br>
> the buffer is added before the existing bounds param? They are of different<br>
> type.)<br>
> > _______________________________________________<br>
> > postgis-devel mailing list<br>
> > <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
> > <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
><br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/d122cf02/attachment.html" rel="noreferrer" target="_blank">http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/d122cf02/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
<br>
------------------------------<br>
<br>
End of postgis-devel Digest, Vol 199, Issue 15<br>
**********************************************<br>
</blockquote></div></div>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>