Problems with ST_OffsetCurve

[jakob ventin]

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

01020000A0FB0B0000210000001904560E4C1F1541022B87BEC72C5A414E62105839E0614085EB51B8571F1541CBA1456EBC2C5A4179E9263108D861402FDD2406711D154183C0CAC1B52C5A41F853E3A59B186140F4FDD478841C15417B14AEFFC62C5A413333333333276140C74B37894F1C15410AD7A3C0CD2C5A418FC2F5285C4F614096438B6CB61C15410C022B17D02C5A41EC51B81E85EB6040736891ED161D1541D578E996CF2C5A414A0C022B87B260405A643B5F4A1D154108AC1CC2D02C5A41B29DEFA7C6BF60405A643BDF781D15414260E540D22C5A414C37894160C160407D3F355E751D1541EC51B8BED52C5A415C8FC2F528D06040D34D62106D1D1541DD2406E1D92C5A41D578E92631EC6040E3A59B44691D1541CDCCCCBCDC2C5A414260E5D022FF604048E17A14571D15417D3F3586E12C5A41B6F3FDD4780D6140B4C876BE441D1541022B87FEE52C5A412DB29DEFA70A61403BDF4F8D191D1541448B6CC7EB2C5A41894160E5D0DE604021B072E8B91C1541F853E32DEE2C5A416F1283C0CAFD6040931804D69E1C1541250681D5F52C5A41C74B3789410461405C8FC2F5AE1C1541105839B4F72C5A41AC1C5A643BEB60400AD7A3F0A01C15416ABC74AB052D5A41E5D022DBF912614000000080811C1541C520B0EA0E2D5A41C520B07268E56040B29DEF27371C15416891ED941E2D5A4137894160E5E06040F853E325E71B1541250681FD2C2D5A415A643BDF4F056140A8C64BB7C81B1541D9CEF773382D5A41E9263108ACD46040273108AC851B154196438BC4412D5A41BC74931804EE6040EC51B89E6D1B154183C0CA11502D5A415C8FC2F528FC5F40E17A142EB21B1541FCA9F1EA502D5A41F853E3A59B245E40E3A59B445C1C154173689105532D5A4154E3A59BC4085F406ABC7493001D15413108AC4C412D5A418716D9CEF75F614060E5D022401D1541FA7E6A7C2E2D5A41CDCCCCCCCCDC6140643BDFCFD21D154185EB51F81F2D5A4146B6F3FDD43C624014AE47E1161E15418716D93E182D5A41736891ED7CFF6240B4C876BE291F1541E17A1406E92C5A411904560E2D7262401904560E4C1F1541022B87BEC72C5A414E62105839E06140
With ST_OffsetCurve values -15 or -17 this runs fine.

SELECT ST_IsSimple(geometry_line) FROM table WHERE id = 111; st_issimple------------- t(1 row)
SELECT ST_IsValid(geometry_line) FROM table WHERE id = 111; st_issimple------------- t(1 row)
As seen from http://trac.osgeo.org/postgis/ticket/2496 a similar problem is reported, which is considered solved by upgrading to latest (?) GEOS & PostGIS version. However, I run this version:
POSTGIS="2.1.0 r11822" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" LIBXML="2.7.6" LIBJSON="UNKNOWN"
and the problem remains.
I have seen some workarounds using ST_SimplifyPreserveTopology. It reduces the problem but doesn't solve it fully. The dataset I need to process is big, and I need to calculate offsets with different parameter values.
Does anyone know if this is a bug? Any ideas on how to proceed?
Best regards,
Jakob Ventin

[Sandro Santilli]

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;

[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 <***@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-***@lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>

[Rémi Cura]

Oups I put a -15 translation in above example, it also works for -16 of
course like required.

Cheers,
Rémi-C


2014-02-03 Rémi Cura <***@gmail.com>:

> 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 <***@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-***@lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>
>
>

[Sandro Santilli]

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;

[Rémi Cura]

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?

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 <***@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-***@lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>

[Sandro Santilli]

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 <***@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-***@lists.osgeo.org
> > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
> >

> _______________________________________________
> postgis-users mailing list
> postgis-***@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

[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: ***@keybit.net
> To: postgis-***@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 <***@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-***@lists.osgeo.org
> > > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
> > >
>
> > _______________________________________________
> > postgis-users mailing list
> > postgis-***@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-***@lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

[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 <***@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: ***@keybit.net
> > To: postgis-***@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 <***@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-***@lists.osgeo.org
> > > > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
> > > >
> >
> > > _______________________________________________
> > > postgis-users mailing list
> > > postgis-***@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-***@lists.osgeo.org
> > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
> _______________________________________________
> postgis-users mailing list
> postgis-***@lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>