<div dir="ltr"><div><div><div><div>Hey, if your data range from 60 000 to 600 000, you can do a translation "-300 000" but it won't help you much, <br></div>but there is no miracle, <br></div>you can't get precise result with very big coordinates (you may need to divide to reduce precision. eg. divide by 100 and round to 0.001, so you would get a precision of 0.1in your system unit).<br>
</div>I proposed a patch for this some time ago, it fixes st_intersects and st_split, but I don't know for st_curveoffset.<br></div>Anyway it was never accepted.<br><br>Cheers,<br><br>Rémi-C<br><div><div><br><br></div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-04 jakob ventin <span dir="ltr"><<a href="mailto:jventin@hotmail.com" target="_blank">jventin@hotmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">Thanks for the quick answers!<div><br></div><div>Yes, I see the problem there Rémi-C, but my data set stretches from ~60 000 to 600 000 in east (x-) coordinate, so that would be more useful for north (y-) coordinate. Tried a few different values, but in those cases the computation crashes some where else. Or am I getting it all wrong?</div>
<div><br></div><div>Opened a ticket at GEOS referencing to this discussion: <a href="http://trac.osgeo.org/geos/ticket/682" target="_blank">http://trac.osgeo.org/geos/ticket/682</a></div><div><br></div><div>(hopefully I put it in the rigtht place)</div>
<div><br></div><div>-jakob</div><div><br></div><div><br><br><div>> Date: Mon, 3 Feb 2014 11:37:03 +0100<br>> From: <a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a><br>> To: <a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
> Subject: Re: [postgis-users] Problems with ST_OffsetCurve<div><div class="h5"><br>> <br>> On Mon, Feb 03, 2014 at 11:29:13AM +0100, Rémi Cura wrote:<br>> > By the way Sandro,<br>> > <br>> > don't you think that Geos should automatically translate the whole input<br>
> > using a pivot point ?<br>> > It would of course be difficult when getting data pieces by pieces (like in<br>> > aggregates),<br>> > but when the whole data is available, why not?<br>> <br>> Isn't that what I just said in my previous mail ? :)<br>
> <br>> If you meant "always" you must be aware that the translation is not always<br>> safe as when you translate back you can introduce collapses. This is a real<br>> case if you search the GEOS bug tracker. So BinaryOp does it only if direct<br>
> computation fails with a TopologyException (if it still does it, as new<br>> versions directly switch to a FixedPrecisionModel, IIRC).<br>> <br>> Again: this is best discussed in a GEOS ticket.<br>> <br>> --strk;<br>
> <br>> > It would considerably help toward reducing the precision issue, and would<br>> > not be so costly (a read of all coordinates to get min/max, then<br>> > subtraction/addition for every coordinate).<br>
> > <br>> > <br>> > Maybe it could be add at the geos input/ouput level, thus not necessitating<br>> > to change all code?<br>> > <br>> > Cheers,<br>> > <br>> > Rémi-C<br>> > <br>
> > <br>> > <br>> > <br>> > 2014-02-03 Sandro Santilli <<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>>:<br>> > <br>> > > 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>> > > 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<br>
> > > ticket,<br>> > > btw).<br>> > ><br>> > > --strk;<br>> > > _______________________________________________<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="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br>> > ><br>> <br>> > _______________________________________________<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="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br>
> <br>> <br>> -- <br>> <br>> () ASCII ribbon campaign -- Keep it simple !<br>> /\ <a href="http://strk.keybit.net/rants/ascii_mails.txt" target="_blank">http://strk.keybit.net/rants/ascii_mails.txt</a> <br>
> _______________________________________________<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="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></div></div> </div></div>
<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></blockquote></div><br></div>