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

Wed Nov 13 07:41:57 PST 2019

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.

Currently the SQL I'm using to buffer by 10% looks like this
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 ))

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.

P.S. It's my first time posting to this list so apologies if it doesn't go
through right.

On Wed, Nov 13, 2019 at 9:22 AM <postgis-devel-request at lists.osgeo.org>
wrote:

>
> Date: Wed, 13 Nov 2019 01:06:20 -0500
> From: Yuri Astrakhan <yuriastrakhan at gmail.com>
> To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: [postgis-devel] Proposal: Adding buffer parameter to
>         ST_TileEnvelope()
> Message-ID:
>         <
> CAJGfNe8vDv5ghoGoa27ONognyiB2Oc-qHgt+bEx4W8nYDwYDAg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/f9bf6a64/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 13 Nov 2019 10:31:44 +0100
> From: "Felix Kunde" <felix-kunde at gmx.de>
> To: postgis-devel at lists.osgeo.org
> Cc: "PostGIS Development Discussion" <postgis-devel at lists.osgeo.org>
> Subject: Re: [postgis-devel] Proposal: Adding buffer parameter to
>         ST_TileEnvelope()
> Message-ID:
>
> <trinity-cab8aeed-70c6-4f55-9ac2-d3376020c4fd-1573637504554 at 3c-app-gmx-bs07
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/96dbc0fc/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 13 Nov 2019 09:10:15 -0500
> From: Yuri Astrakhan <yuriastrakhan at gmail.com>
> To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: Re: [postgis-devel] Proposal: Adding buffer parameter to
>         ST_TileEnvelope()
> Message-ID:
>         <CAJGfNe96vEctzH22Lz6jOET+2+i3E8Lg75+kLQHtU=
> M8of7CCQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Wrapping would look like this for srid=3857, and more complex for other
> srids (assuming my math is correct). I think having it as part of the
> ST_TileEnvelope will simplify this very common use case, avoid errors, and
> will run faster.
>
> ST_Expand(
>   ST_TileEnvelope(:zoom, :x, :y),
>   20037508.34 * 2 / (2 ^ :zoom) / :extent * :buffer
> )
>
> Both :extent and :buffer are defined in ST_AsMVTGeom().
>
> Note that the same argument could have been used for ST_TileEnvelope()
> itself -- it can be easily implemented with a short function. but it was
> implemented as a native PostGIS function because of how frequently it is
> used.
> https://github.com/mapbox/postgis-vt-util/blob/master/src/TileBBox.sql#L17
>
>
> On Wed, Nov 13, 2019 at 4:31 AM Felix Kunde <felix-kunde at gmx.de> wrote:
>
> > What speaks against ST_Expand(ST_TileEnvelope ... ?
> >
> > *Gesendet:* Mittwoch, 13. November 2019 um 07:06 Uhr
> > *Von:* "Yuri Astrakhan" <yuriastrakhan at gmail.com>
> > *An:* "PostGIS Development Discussion" <postgis-devel at lists.osgeo.org>
> > *Betreff:* [postgis-devel] Proposal: Adding buffer parameter to
> > ST_TileEnvelope()
> > 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/a2da691e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Wed, 13 Nov 2019 08:14:42 -0600
> From: Paul Ramsey <pramsey at cleverelephant.ca>
> To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: Re: [postgis-devel] Proposal: Adding buffer parameter to
>         ST_TileEnvelope()
> Message-ID: <75FEEE10-D876-4FE4-AB87-A09DE6396157 at cleverelephant.ca>
> Content-Type: text/plain;       charset=utf-8
>
> 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
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 13 Nov 2019 09:22:01 -0500
> From: Yuri Astrakhan <yuriastrakhan at gmail.com>
> To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: Re: [postgis-devel] Proposal: Adding buffer parameter to
>         ST_TileEnvelope()
> Message-ID:
>         <
> CAJGfNe-+k1wSM2poazmTABhEFZTD24G3expA4FsZDCqP6bD5oA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
>
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/d122cf02/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
> ------------------------------
>
> End of postgis-devel Digest, Vol 199, Issue 15
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191113/33c0d214/attachment-0001.html>