<div dir="ltr"><div><div><div><div>By the way Sandro,<br><br>don't you think that Geos should automatically translate the whole input using a pivot point ?<br></div>It would of course be difficult when getting data pieces by pieces (like in aggregates), <br>
</div>but when the whole data is available, why not?<br><br></div>It would considerably help toward reducing the precision issue, and would not be so costly (a read of all coordinates to get min/max, then subtraction/addition for every coordinate).<br>
<br><br></div><div>Maybe it could be add at the geos input/ouput level, thus not necessitating to change all code?<br></div><div><br></div>Cheers,<br><br>Rémi-C<br><div><div><div><div><br><br></div></div></div></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-03 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Feb 03, 2014 at 10:54:13AM +0100, Rémi Cura wrote:<br>
> Hey,<br>
> you use far too big coordinates.<br>
> Please consider using st translate on your data, then curve offset, then<br>
> inverse translate.<br>
<br>
</div>Speaking of which, this treatment is one of those performed on catching<br>
an exception in binary operations, maybe the GEOSOffsetCurve method should<br>
be changed to _use_ the BinaryOp class (detail more useful in a GEOS ticket,<br>
btw).<br>
<div class="HOEnZb"><div class="h5"><br>
--strk;<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br>
</div></div></blockquote></div><br></div>