<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">вт, 10 июл. 2018 г. в 12:48, Pavan Deolasee <<a href="mailto:pavan.deolasee@gmail.com">pavan.deolasee@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 10, 2018 at 12:22 PM, Darafei "Komяpa" Praliaskouski <span dir="ltr"><<a href="mailto:me@komzpa.net" target="_blank">me@komzpa.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><div><br></div></span><div>What you can try is to short-circuit ST_Expand to ST_Buffer for now. It's more expensive computationally, but for most practical use cases the box it produces should be similar to that of ST_Expand, and serialized geometry should produce the same box on both sides of serialization.</div><div> </div></div></div></blockquote></div><br clear="all"></div></div><div dir="ltr"><div class="gmail_extra"><div>Thanks for the tip. That seems to do the trick. Apart from the performance impact, can this cause any regression?</div></div></div></blockquote><div><br></div><div>ST_Intersects(ST_Buffer()) is different from ST_Within() on the edge, by <1%.</div><div>ST_Buffer on geography is actually ST_Buffer on plane, so for long geometries there are bigger error margins.</div><div><br></div><div>Anything on the scale of city / buildings should be fine.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div> FWIW PostGIS regression tests does not show any new failure, but anything specific I should test?</div></div></div></blockquote><div><br></div><div>Test whether you can replace ST_DWithin(a, b, eps) with ST_Intersects(ST_Buffer(a, eps), b).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div> With regard to performance impact, could it be material? And if so, in what circumstances?</div></div></div></blockquote><div><br></div><div>You're replacing O(N) with somewhat like O(NlogN). ST_Expand output size is O(N), ST_Buffer's is up to O(4*N*quad_segs), where quad_segs is usually 8.</div><div><br></div><div>A scenario with massive regression I see: you have a city polygon and want all buildings in it while your db holds just that city and a bit around. This way you calculate and throw away a buffer for every building in that city.</div><div><br></div><div>A scenario with almost no regression: you have a GPS position of someone and want to get shops within N meters around them. You buffer their point once, select some small amount of shops around and buffer only them (as ST_DWithin buffers both sides).</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br></div><div>Thanks,</div><div>Pavan</div><div><br></div>-- <br><div class="m_-6464473873089136691gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"> Pavan Deolasee                   <a href="http://www.2ndQuadrant.com/" target="_blank">http://www.2ndQuadrant.com/</a><br> PostgreSQL Development, 24x7 Support, Training & Services</div></div></div></div>
</div></div><div dir="ltr"><div class="gmail_extra"></div></div>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a></blockquote></div></div>