<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><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: strk@keybit.net<br>> To: postgis-users@lists.osgeo.org<br>> Subject: Re: [postgis-users] Problems with ST_OffsetCurve<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 <strk@keybit.net>:<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>> > > postgis-users@lists.osgeo.org<br>> > > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users<br>> > ><br>> <br>> > _______________________________________________<br>> > postgis-users mailing list<br>> > postgis-users@lists.osgeo.org<br>> > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users<br>> <br>> <br>> -- <br>> <br>> () ASCII ribbon campaign -- Keep it simple !<br>> /\ http://strk.keybit.net/rants/ascii_mails.txt <br>> _______________________________________________<br>> postgis-users mailing list<br>> postgis-users@lists.osgeo.org<br>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users<br></div></div> </div></body>
</html>