[postgis-users] Problems with ST_OffsetCurve

[jakob ventin]

Thanks for the quick answers!
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?
Opened a ticket at GEOS referencing to this discussion: http://trac.osgeo.org/geos/ticket/682
(hopefully I put it in the rigtht place)
-jakob


> Date: Mon, 3 Feb 2014 11:37:03 +0100
> From: strk at keybit.net
> To: postgis-users at lists.osgeo.org
> Subject: Re: [postgis-users] Problems with ST_OffsetCurve
> 
> On Mon, Feb 03, 2014 at 11:29:13AM +0100, Rémi Cura wrote:
> > By the way Sandro,
> > 
> > don't you think that Geos should automatically translate the whole input
> > using a pivot point ?
> > It would of course be difficult when getting data pieces by pieces (like in
> > aggregates),
> > but when the whole data is available, why not?
> 
> Isn't that what I just said in my previous mail ? :)
> 
> If you meant "always" you must be aware that the translation is not always
> safe as when you translate back you can introduce collapses. This is a real
> case if you search the GEOS bug tracker. So BinaryOp does it only if direct
> computation fails with a TopologyException (if it still does it, as new
> versions directly switch to a FixedPrecisionModel, IIRC).
> 
> Again: this is best discussed in a GEOS ticket.
> 
> --strk;
> 
> > 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).
> > 
> > 
> > Maybe it could be add at the geos input/ouput level, thus not necessitating
> > to change all code?
> > 
> > Cheers,
> > 
> > Rémi-C
> > 
> > 
> > 
> > 
> > 2014-02-03 Sandro Santilli <strk at keybit.net>:
> > 
> > > On Mon, Feb 03, 2014 at 10:54:13AM +0100, Rémi Cura wrote:
> > > > Hey,
> > > > you use far too big coordinates.
> > > > Please consider using st translate on your data, then curve offset, then
> > > > inverse translate.
> > >
> > > Speaking of which, this treatment is one of those performed on catching
> > > an exception in binary operations, maybe the GEOSOffsetCurve method should
> > > be changed to _use_ the BinaryOp class (detail more useful in a GEOS
> > > ticket,
> > > btw).
> > >
> > > --strk;
> > > _______________________________________________
> > > postgis-users mailing list
> > > postgis-users at lists.osgeo.org
> > > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
> > >
> 
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users at lists.osgeo.org
> > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
> 
> 
> -- 
> 
>  ()  ASCII ribbon campaign  --  Keep it simple !
>  /\  http://strk.keybit.net/rants/ascii_mails.txt  
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20140204/38f65253/attachment.html>