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

Yuri Astrakhan yuriastrakhan at gmail.com
Wed Nov 13 09:44:38 PST 2019 

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.

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).

On Wed, Nov 13, 2019 at 10:42 AM Michael Davis <michael.davis at spatialkey.com>
wrote:

> 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
>> **********************************************
>>
> _______________________________________________
> 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/b8981098/attachment-0001.html>

More information about the postgis-devel mailing list