Hi Pavan, вт, 10 июл. 2018 г. в 12:48, Pavan Deolasee <[email protected]>:
> > On Tue, Jul 10, 2018 at 12:22 PM, Darafei "Komяpa" Praliaskouski < > [email protected]> wrote: > >> >> 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. >> >> > > Thanks for the tip. That seems to do the trick. Apart from the performance > impact, can this cause any regression? FWIW PostGIS regression tests does > not show any new failure, but anything specific I should test? With regard > to performance impact, could it be material? And if so, in what > circumstances? > I've created a ticket for your issue so we can do something about it. https://trac.osgeo.org/postgis/ticket/4122#ticket Please check if everything's right in it. You said you're willing to write a patch. An approach I see now would be is to take box3d->geometry code from here: https://github.com/postgis/postgis/blob/587badb8cca5b59f734c1a0d689024f0287bc47b/postgis/lwgeom_box3d.c#L183 Then, replace the POLYGON, LINESTRING and so on generation with generation of MULTIPOINT with just points. In geography lines are curvy, so unfortunately drawing a 3D shape with only endpoints will be too wavy to be correct. Transform box coords to normal using cart2geog just like here: https://github.com/postgis/postgis/blob/fce3e121f3726aabfe8cfc6e4d98f31c6713c0f4/liblwgeom/g_serialized.c#L275 All this new code should go to a function here: https://github.com/postgis/postgis/blob/f1f6de48cd205e620e56aca8157080d7a34a6888/postgis/geography_measurement.c#L479 A PR can be sent on github, https://github.com/postgis/postgis - or post a patch in any convenient format.
_______________________________________________ postgis-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/postgis-users
