[postgis-users] Problems with ST_OffsetCurve

[Rémi Cura]

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,
but there is no miracle,
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).
I proposed a patch for this some time ago, it fixes st_intersects and
st_split, but I don't know for st_curveoffset.
Anyway it was never accepted.

Cheers,

Rémi-C




2014-02-04 jakob ventin <jventin at hotmail.com>:

> 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
>
> _______________________________________________
> 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/d26a8753/attachment.html>