<div dir="ltr">Uglier is a relative term :))<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 13, 2019 at 9:59 AM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</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 style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Nov 13, 2019, at 8:22 AM, Yuri Astrakhan <<a href="mailto:yuriastrakhan@gmail.com" target="_blank">yuriastrakhan@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Paul, I was thinking of using the same definitions as in ST_AsMVTGeom():<div><br></div><div>* buffer is the buffer distance in tile coordinate space to optionally clip geometries.<br></div><div><br></div><div>So the buffer would be in the tile's units, and depend on the zoom level.</div><div>I suspect we have to add extent parameter too, rather than use default 4096.</div></div></div></blockquote><div><br></div><div>Yeah, that’s what I thought… it gets uglier and uglier, no?</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 13, 2019 at 9:14 AM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</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">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>
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>
_______________________________________________<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" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></div></blockquote></div><br></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>