[postgis-users] Problems with ST_OffsetCurve

[Rémi Cura]

Hey,
you use far too big coordinates.
Please consider using st translate on your data, then curve offset, then
inverse translate.
This is mandatory (when using so many digits, you artificially increase the
need for precision in numeric computing, which is problematic).

It is true for all computation, also for "cleanness", you should use a
custom srid defined as a translated version of your orgininal srid, and not
manually put the translate number like I did in the following. It is best
practice and easier to read/correct/maintain/ reuse.

SELECT ST_AsText(ST_Translate(ST_Offsetcurve(ST_Translate(geom,-346000,
-6861000),-15), +346000,+6861000)) FROM
ST_AsText('01020000A0FB0B0000210000001904560E4C1F1541022B87BEC72C5A414E62105839E0614085EB51B8571F1541CBA1456EBC2C5A4179E9263108D861402FDD2406711D154183C0CAC1B52C5A41F853E3A59B186140F4FDD478841C15417B14AEFFC62C5A413333333333276140C74B37894F1C15410AD7A3C0CD2C5A418FC2F5285C4F614096438B6CB61C15410C022B17D02C5A41EC51B81E85EB6040736891ED161D1541D578E996CF2C5A414A0C022B87B260405A643B5F4A1D154108AC1CC2D02C5A41B29DEFA7C6BF60405A643BDF781D15414260E540D22C5A414C37894160C160407D3F355E751D1541EC51B8BED52C5A415C8FC2F528D06040D34D62106D1D1541DD2406E1D92C5A41D578E92631EC6040E3A59B44691D1541CDCCCCBCDC2C5A414260E5D022FF604048E17A14571D15417D3F3586E12C5A41B6F3FDD4780D6140B4C876BE441D1541022B87FEE52C5A412DB29DEFA70A61403BDF4F8D191D1541448B6CC7EB2C5A41894160E5D0DE604021B072E8B91C1541F853E32DEE2C5A416F1283C0CAFD6040931804D69E1C1541250681D5F52C5A41C74B3789410461405C8FC2F5AE1C1541105839B4F72C5A41AC1C5A643BEB60400AD7A3F0A01C15416ABC74AB052D5A41E5D022DBF912614000000080811C1541C520B0EA0E2D5A41C520B07268E56040B29DEF27371C15416891ED941E2D5A4137894160E5E06040F853E325E71B1541250681FD2C2D5A415A643BDF4F056140A8C64BB7C81B1541D9CEF773382D5A41E9263108ACD46040273108AC851B154196438BC4412D5A41BC74931804EE6040EC51B89E6D1B154183C0CA11502D5A415C8FC2F528FC5F40E17A142EB21B1541FCA9F1EA502D5A41F853E3A59B245E40E3A59B445C1C154173689105532D5A4154E3A59BC4085F406ABC7493001D15413108AC4C412D5A418716D9CEF75F614060E5D022401D1541FA7E6A7C2E2D5A41CDCCCCCCCCDC6140643BDFCFD21D154185EB51F81F2D5A4146B6F3FDD43C624014AE47E1161E15418716D93E182D5A41736891ED7CFF6240B4C876BE291F1541E17A1406E92C5A411904560E2D7262401904560E4C1F1541022B87BEC72C5A414E62105839E06140'
) AS geom

Conceptually, it is more difficult for a computer to do 684738+1 than 12+1 .

Also , it should be noted that sometime curveoffset can't give a correct
answer because there isn't a well defined one (like almost boucling lines).

Cheers,

Rémi-C


2014-02-03 Sandro Santilli <strk at keybit.net>:

> On Mon, Feb 03, 2014 at 11:43:37AM +0300, jakob ventin wrote:
> > Hello all,
> > I am using ST_OffsetCurve function to calculate offsets for lines and
> polygons. I have a quit large amount of data, several tens of thousands of
> features which I have to do these calculations for in an automated
> processs. Now I have run into a problem: St_OffsetCurve crashes for some
> geometries, e.g this geometry and value -16 for ST_OffsetCurve:
> >  SELECT ST_OffsetCurve(geometry_line,-16) FROM table WHERE id =
> 111;ERROR:  GEOSOffsetCurve: TopologyException: assigned depths do not
> match at 346051.04711531324 6861597.9481203193
>
> Sounds like a robustness problem. It would be interesting to
> see if using a fixed PrecisionModel solved the issue.
> You can file a ticket for GEOS, an XML test for GEOS would
> be able to test with both floating and fixed PrecisionModel.
>
> If fixed precisionmodel solves it this would be yet another
> reason to expose support for that into PostGIS...
>
> --strk;
> _______________________________________________
> 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/20140203/5d75808b/attachment.html>