GEOS NG Regression Review

Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

GEOS NG Regression Review

Paul Ramsey
All, after receiving the latest improvement from Martin, to allow overlay to return mixed dimensionality results, which harmonizes with old behaviour, and porting that improvement, I have flipped the default overlay functions (setting DISABLE_OVERLAYNG to OFF) to use NG, and then run the GEOS internal regression suite.

That means the following operations all use NG overlay, instead of the old overlay.

Geometry->Intersection(Geometry)
Geometry->Difference(Geometry)
Geometry->SynDifference(Geometry)
Geometry->Union(Geometry)
Geometry->Union()

Doing this run over the whole suite basically compares the behaviour of the new overlay to all the examples we have of the old behaviour.

The result of that work can be reviewed here:

https://docs.google.com/document/d/1TDm2aR4a7O41-soS-25Xog1EdQcjmvKCnKltxjbxOC0/edit#

In general, all the failures are entirely defensible. The new results aren't the same as the old ones, but they are different in ways that generally fall into a "who cares" bucket or a "that's actually better" bucket.

If we are to move to NG as our default overlay engine, I'd simply recommend updating the tests to expect the NG results. They seem just fine to me.

The next major effort of testing on NG overlay needs to be the PostGIS regression suite, which has a lot of routines that will exercise the code in interesting and different ways.

ATB,

P


PS - Although we know that GEOS has Z-coordinate handling in overlay, we have no regression failures in Z-coordinate handling, which means we probably are low on unit and integration tests for that behaviour. Something to improve when we get that last compatibility feature from Martin.

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review

Paul Ramsey

> https://docs.google.com/document/d/1TDm2aR4a7O41-soS-25Xog1EdQcjmvKCnKltxjbxOC0/edit#

I have run the PostGIS regression suite with the GEOS 3.9 NG build installed, and analyzed all the discrepencies, and there are very few of them (thanks Regina for fixing up the first route of normalizations).

Discussion of each case is at the end of the document linked above.

* There were a few more normalizations to add, in the split and tickets tests.
* There was one cunit makevalid test that duplicates an existing test in GEOS. It can fairly be removed, IMO.
* There was one small discrepency in a subdivide test, which might need to be version guarded, or maybe just altered slightly. The results appeared consistent for practical purposes (identical areas, etc).
* Despite worries, only one file in topology showed any differences. topogeo_addlinestring.sql needs to be looked at by a topology expert, Sandro do you think you could?

I think we are very close to being able to make NG the default overlay engine in GEOS. The task would look like:

GEOS
* Make NG the default.
* Update the small set of GEOS regression tests that need changes to expect NG outputs.

PostGIS
* Remove duplicated cunit makevalid tset
* Normalize test outputs as necessary (already done on branch, to be merged shortly)
* Version guard or remove the subdivide regress test in postgis.
* Version guard or fix the topology failure case (depends on what Sandro finds is the root cause)
* Version guard the tickets test error messages and only test against 3.9

Thoughts?

P
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review

Paul Ramsey


> On Sep 16, 2020, at 1:25 PM, Paul Ramsey <[hidden email]> wrote:
>
>
>> https://docs.google.com/document/d/1TDm2aR4a7O41-soS-25Xog1EdQcjmvKCnKltxjbxOC0/edit#
>
> I have run the PostGIS regression suite with the GEOS 3.9 NG build installed, and analyzed all the discrepencies, and there are very few of them (thanks Regina for fixing up the first route of normalizations).
>
> Discussion of each case is at the end of the document linked above.
>
> * There were a few more normalizations to add, in the split and tickets tests.
> * There was one cunit makevalid test that duplicates an existing test in GEOS. It can fairly be removed, IMO.
> * There was one small discrepency in a subdivide test, which might need to be version guarded, or maybe just altered slightly. The results appeared consistent for practical purposes (identical areas, etc).
> * Despite worries, only one file in topology showed any differences. topogeo_addlinestring.sql needs to be looked at by a topology expert, Sandro do you think you could?
>
> I think we are very close to being able to make NG the default overlay engine in GEOS. The task would look like:

Subject to completing Z coordinate preservation in NG overlay, first.

P

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review (GDAL feedback)

Even Rouault-2
In reply to this post by Paul Ramsey

Hi Paul,

 

I gave a try to GEOS git head built with -DDISABLE_OVERLAYNG=OFF, and ran it against GDAL autotest suite.

 

The needed changes are in https://github.com/OSGeo/gdal/pull/2942

 

Most of them are boring, due to polygon vertices not being returned in the same order, and fixed by using spatial equality instead of plain WKT comparison.

 

One non-trivial change I had to do was related to a convoluted way of how OGR tries to split line or polygon geometries crossing the antimeridian, when reprojecting from a projected CRS crossing the antimedian (e.g. UTM zone 60), to geographic coordinates. The resulting geometry needs to be a multilinestring or multipolygon with one (or several) part close to longitude +180 and another one close to longitude -180. Typically needed when reprojecting geometries for GeoJSON RFC7946 compliance.

 

1) For each segment of the input geometry that crosses the antimeridian, OGR determines by dichotomy the coordinates, in the projected CRS, of the intersection with the antimeridian. This leads to a list of points P_antimeridian[], that is sorted by increasing y.

2) Previously, OGR built a polygon, at the left of the antimeridian, whose right edge are points whose x is at P_antimeridian[].x - epsilon, and another one, at the right of the antimeridian, whose left edge are points whose x is at P_antimeridian[].x + epsilon. Then it creates a multipolygon with those 2 polygons.

3) Then it intersects the input geometry with those 2 multipolygons, which leads to a multi-geometry not crossing the antimeridian.

4) And finally it reprojects that geometry to geographic coordinates.

 

The intersection of the input geometry with this multipolygon of 2 parts can be shown with:

 

from osgeo import ogr

 

# input geometry crossing the antimeridian (UTM 60N)

geom = ogr.CreateGeometryFromWkt('LINESTRING(832864.275023695 0,835092.849076364 0)')

 

# multipolygon with one part left to the antimeridian, one part right

geom2 = ogr.CreateGeometryFromWkt('MULTIPOLYGON (((832864.275023695 0.0,833978.556808034 -0.000110682755987,833978.556808034 0.0,833978.556808034 0.000110682755987,832864.275023695 0.0,832864.275023695 0.0)),((835092.849076364 0.0,833978.557030887 -0.000110682755987,833978.557030887 0.0,833978.557030887 0.000110682755987,835092.849076364 0.0,835092.849076364 0.0)))')

 

# intersection

print(geom.Intersection(geom2))

 

With OverlayNG, the following leads to a LINESTRING EMPTY, whereas with GEOS 3.8something, it leads to the expected result of

MULTILINESTRING ((832864.275023695 0.0,833978.556808034 0.0),(833978.557030887 0.0,835092.849076364 0.0))

 

I'm not sure if the OverlayNG result is a feature or a bug.

 

Anyway, I've changed the GDAL code to compute the difference between the input geometry and a polygon with one edge with points whose x is at P_antimeridian[].x - epsilon and another one with points whose x is at P_antimeridian[].x + epsilon. This is more straightforward, and works with any GEOS version.

 

(by the way, I don't think the GDAL autotest suite exercices much GEOS Z handling)

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review

Sandro Santilli-4
In reply to this post by Paul Ramsey
On Wed, Sep 16, 2020 at 01:25:39PM -0700, Paul Ramsey wrote:
>
> > https://docs.google.com/document/d/1TDm2aR4a7O41-soS-25Xog1EdQcjmvKCnKltxjbxOC0/edit#
>

> * Despite worries, only one file in topology showed any differences. topogeo_addlinestring.sql needs to be looked at by a topology expert, Sandro do you think you could?

A quick look suggests this is just a lack of normalization from
the output of OverlayNG (did the old overlay normalize internally ?)

--strk;
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review

Paul Ramsey


> On Sep 17, 2020, at 6:54 AM, Sandro Santilli <[hidden email]> wrote:
>
> On Wed, Sep 16, 2020 at 01:25:39PM -0700, Paul Ramsey wrote:
>>
>>> https://docs.google.com/document/d/1TDm2aR4a7O41-soS-25Xog1EdQcjmvKCnKltxjbxOC0/edit#
>>
>
>> * Despite worries, only one file in topology showed any differences. topogeo_addlinestring.sql needs to be looked at by a topology expert, Sandro do you think you could?
>
> A quick look suggests this is just a lack of normalization from
> the output of OverlayNG (did the old overlay normalize internally ?)

No, neither normalizes, it's wasted overhead except in testing. Things just come out of the graphs in different orders.

P.

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review

Sandro Santilli-4
On Thu, Sep 17, 2020 at 06:55:16AM -0700, Paul Ramsey wrote:

>
>
> > On Sep 17, 2020, at 6:54 AM, Sandro Santilli <[hidden email]> wrote:
> >
> > On Wed, Sep 16, 2020 at 01:25:39PM -0700, Paul Ramsey wrote:
> >>
> >>> https://docs.google.com/document/d/1TDm2aR4a7O41-soS-25Xog1EdQcjmvKCnKltxjbxOC0/edit#
> >>
> >
> >> * Despite worries, only one file in topology showed any differences. topogeo_addlinestring.sql needs to be looked at by a topology expert, Sandro do you think you could?
> >
> > A quick look suggests this is just a lack of normalization from
> > the output of OverlayNG (did the old overlay normalize internally ?)
>
> No, neither normalizes, it's wasted overhead except in testing. Things just come out of the graphs in different orders.

Well the result seem to be compatible, just different order,
so this case could be threated like the other ones of expecting
different results based on GEOS version.

--strk;
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review (GDAL feedback)

Martin Davis-3
In reply to this post by Even Rouault-2
Thanks for testing, Even.

Interestingly, in JTS the test case you give below for OverlayNG.intersection actually returns the same result as the old code:

MULTILINESTRING ((833978.557030887 0, 835092.849076364 0), (832864.275023695 0, 833978.556808034 0))

So this is something to look into on the GEOS side.

On Thu, Sep 17, 2020 at 4:39 AM Even Rouault <[hidden email]> wrote:


 

The intersection of the input geometry with this multipolygon of 2 parts can be shown with:

 

from osgeo import ogr

 

# input geometry crossing the antimeridian (UTM 60N)

geom = ogr.CreateGeometryFromWkt('LINESTRING(832864.275023695 0,835092.849076364 0)')

 

# multipolygon with one part left to the antimeridian, one part right

geom2 = ogr.CreateGeometryFromWkt('MULTIPOLYGON (((832864.275023695 0.0,833978.556808034 -0.000110682755987,833978.556808034 0.0,833978.556808034 0.000110682755987,832864.275023695 0.0,832864.275023695 0.0)),((835092.849076364 0.0,833978.557030887 -0.000110682755987,833978.557030887 0.0,833978.557030887 0.000110682755987,835092.849076364 0.0,835092.849076364 0.0)))')

 

# intersection

print(geom.Intersection(geom2))

 

With OverlayNG, the following leads to a LINESTRING EMPTY, whereas with GEOS 3.8something, it leads to the expected result of

MULTILINESTRING ((832864.275023695 0.0,833978.556808034 0.0),(833978.557030887 0.0,835092.849076364 0.0))


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review (GDAL feedback)

Paul Ramsey


> On Sep 17, 2020, at 8:50 AM, Martin Davis <[hidden email]> wrote:
>
> Thanks for testing, Even.
>
> Interestingly, in JTS the test case you give below for OverlayNG.intersection actually returns the same result as the old code:
>
> MULTILINESTRING ((833978.557030887 0, 835092.849076364 0), (832864.275023695 0, 833978.556808034 0))
>
> So this is something to look into on the GEOS side.

I have confirmed this happens in GEOS, with a little unit test, so it's nothing to do with GDAL. Looks like a morning in the debugger awaits.

P


>
> On Thu, Sep 17, 2020 at 4:39 AM Even Rouault <[hidden email]> wrote:
>
>  
> The intersection of the input geometry with this multipolygon of 2 parts can be shown with:
>  
> from osgeo import ogr
>  
> # input geometry crossing the antimeridian (UTM 60N)
> geom = ogr.CreateGeometryFromWkt('LINESTRING(832864.275023695 0,835092.849076364 0)')
>  
> # multipolygon with one part left to the antimeridian, one part right
> geom2 = ogr.CreateGeometryFromWkt('MULTIPOLYGON (((832864.275023695 0.0,833978.556808034 -0.000110682755987,833978.556808034 0.0,833978.556808034 0.000110682755987,832864.275023695 0.0,832864.275023695 0.0)),((835092.849076364 0.0,833978.557030887 -0.000110682755987,833978.557030887 0.0,833978.557030887 0.000110682755987,835092.849076364 0.0,835092.849076364 0.0)))')
>  
> # intersection
> print(geom.Intersection(geom2))
>  
> With OverlayNG, the following leads to a LINESTRING EMPTY, whereas with GEOS 3.8something, it leads to the expected result of
> MULTILINESTRING ((832864.275023695 0.0,833978.556808034 0.0),(833978.557030887 0.0,835092.849076364 0.0))
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review (GDAL feedback)

Paul Ramsey
Problem found and fixed, thanks Even!

https://github.com/libgeos/geos/commit/49ac5aa4

P

> On Sep 17, 2020, at 9:02 AM, Paul Ramsey <[hidden email]> wrote:
>
>
>
>> On Sep 17, 2020, at 8:50 AM, Martin Davis <[hidden email]> wrote:
>>
>> Thanks for testing, Even.
>>
>> Interestingly, in JTS the test case you give below for OverlayNG.intersection actually returns the same result as the old code:
>>
>> MULTILINESTRING ((833978.557030887 0, 835092.849076364 0), (832864.275023695 0, 833978.556808034 0))
>>
>> So this is something to look into on the GEOS side.
>
> I have confirmed this happens in GEOS, with a little unit test, so it's nothing to do with GDAL. Looks like a morning in the debugger awaits.
>
> P
>
>
>>
>> On Thu, Sep 17, 2020 at 4:39 AM Even Rouault <[hidden email]> wrote:
>>
>>
>> The intersection of the input geometry with this multipolygon of 2 parts can be shown with:
>>
>> from osgeo import ogr
>>
>> # input geometry crossing the antimeridian (UTM 60N)
>> geom = ogr.CreateGeometryFromWkt('LINESTRING(832864.275023695 0,835092.849076364 0)')
>>
>> # multipolygon with one part left to the antimeridian, one part right
>> geom2 = ogr.CreateGeometryFromWkt('MULTIPOLYGON (((832864.275023695 0.0,833978.556808034 -0.000110682755987,833978.556808034 0.0,833978.556808034 0.000110682755987,832864.275023695 0.0,832864.275023695 0.0)),((835092.849076364 0.0,833978.557030887 -0.000110682755987,833978.557030887 0.0,833978.557030887 0.000110682755987,835092.849076364 0.0,835092.849076364 0.0)))')
>>
>> # intersection
>> print(geom.Intersection(geom2))
>>
>> With OverlayNG, the following leads to a LINESTRING EMPTY, whereas with GEOS 3.8something, it leads to the expected result of
>> MULTILINESTRING ((832864.275023695 0.0,833978.556808034 0.0),(833978.557030887 0.0,835092.849076364 0.0))
>> _______________________________________________
>> geos-devel mailing list
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review

Joris Van den Bossche
In reply to this post by Sandro Santilli-4
Hi all,

First, thanks for all the work on improving the overlay operations!

I ran the test suites of Shapely and PyGEOS with GEOS master and DISABLE_OVERLAYNG=OFF.

For PyGEOS there are 2 failing tests related to MakeValid. But both are just a change in coordinate order and solved by using spatial equality or normalizing the resulting and expected multipolygon first.
And for Shapely there is 1 failing test caused by a union operation returning a GeometryCollection with the parts in a different order, so again only a normalization issue.

So basically nothing to report. But that probably says more about the Shapely/PyGEOS test suites (which mostly test the *bindings* with simple cases, and don't include much complex geometry test cases deferring that to GEOS), than about OverlayNG not causing behaviour changes ;)

Best,
Joris

On Thu, 17 Sep 2020 at 17:18, Sandro Santilli <[hidden email]> wrote:
On Thu, Sep 17, 2020 at 06:55:16AM -0700, Paul Ramsey wrote:
>
>
> > On Sep 17, 2020, at 6:54 AM, Sandro Santilli <[hidden email]> wrote:
> >
> > On Wed, Sep 16, 2020 at 01:25:39PM -0700, Paul Ramsey wrote:
> >>
> >>> https://docs.google.com/document/d/1TDm2aR4a7O41-soS-25Xog1EdQcjmvKCnKltxjbxOC0/edit#
> >>
> >
> >> * Despite worries, only one file in topology showed any differences. topogeo_addlinestring.sql needs to be looked at by a topology expert, Sandro do you think you could?
> >
> > A quick look suggests this is just a lack of normalization from
> > the output of OverlayNG (did the old overlay normalize internally ?)
>
> No, neither normalizes, it's wasted overhead except in testing. Things just come out of the graphs in different orders.

Well the result seem to be compatible, just different order,
so this case could be threated like the other ones of expecting
different results based on GEOS version.

--strk;
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review

Paul Ramsey


> On Sep 18, 2020, at 2:39 AM, Joris Van den Bossche <[hidden email]> wrote:
>
> Hi all,
>
> First, thanks for all the work on improving the overlay operations!
>
> I ran the test suites of Shapely and PyGEOS with GEOS master and DISABLE_OVERLAYNG=OFF.
>
> For PyGEOS there are 2 failing tests related to MakeValid. But both are just a change in coordinate order and solved by using spatial equality or normalizing the resulting and expected multipolygon first.
> And for Shapely there is 1 failing test caused by a union operation returning a GeometryCollection with the parts in a different order, so again only a normalization issue.
>
> So basically nothing to report. But that probably says more about the Shapely/PyGEOS test suites (which mostly test the *bindings* with simple cases, and don't include much complex geometry test cases deferring that to GEOS), than about OverlayNG not causing behaviour changes ;)

Every little bit counts! Thanks for testing!
P


>
> Best,
> Joris
>
> On Thu, 17 Sep 2020 at 17:18, Sandro Santilli <[hidden email]> wrote:
> On Thu, Sep 17, 2020 at 06:55:16AM -0700, Paul Ramsey wrote:
> >
> >
> > > On Sep 17, 2020, at 6:54 AM, Sandro Santilli <[hidden email]> wrote:
> > >
> > > On Wed, Sep 16, 2020 at 01:25:39PM -0700, Paul Ramsey wrote:
> > >>
> > >>> https://docs.google.com/document/d/1TDm2aR4a7O41-soS-25Xog1EdQcjmvKCnKltxjbxOC0/edit#
> > >>
> > >
> > >> * Despite worries, only one file in topology showed any differences. topogeo_addlinestring.sql needs to be looked at by a topology expert, Sandro do you think you could?
> > >
> > > A quick look suggests this is just a lack of normalization from
> > > the output of OverlayNG (did the old overlay normalize internally ?)
> >
> > No, neither normalizes, it's wasted overhead except in testing. Things just come out of the graphs in different orders.
>
> Well the result seem to be compatible, just different order,
> so this case could be threated like the other ones of expecting
> different results based on GEOS version.
>
> --strk;
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: GEOS NG Regression Review

Martin Davis-3
In reply to this post by Joris Van den Bossche
Thanks for testing, Joris.

It makes sense that downstream project unit tests are focussed on the code that is net new to the project.  Still, it is always reassuring to run a set of functional tests as well. One way to do this fairly easily would be to develop a test runer that is able to exercise the JTS / GEOS XML test suites [1][2].  That might be a nice addition to Shapely et al.


And would be great is to retry some of the (numerous) Shapely issues filed which involve overlay robust problems.  Here's a selection:




On Fri, Sep 18, 2020 at 2:40 AM Joris Van den Bossche <[hidden email]> wrote:
Hi all,

First, thanks for all the work on improving the overlay operations!

I ran the test suites of Shapely and PyGEOS with GEOS master and DISABLE_OVERLAYNG=OFF.

For PyGEOS there are 2 failing tests related to MakeValid. But both are just a change in coordinate order and solved by using spatial equality or normalizing the resulting and expected multipolygon first.
And for Shapely there is 1 failing test caused by a union operation returning a GeometryCollection with the parts in a different order, so again only a normalization issue.

So basically nothing to report. But that probably says more about the Shapely/PyGEOS test suites (which mostly test the *bindings* with simple cases, and don't include much complex geometry test cases deferring that to GEOS), than about OverlayNG not causing behaviour changes ;)

Best,
Joris

On Thu, 17 Sep 2020 at 17:18, Sandro Santilli <[hidden email]> wrote:
On Thu, Sep 17, 2020 at 06:55:16AM -0700, Paul Ramsey wrote:
>
>
> > On Sep 17, 2020, at 6:54 AM, Sandro Santilli <[hidden email]> wrote:
> >
> > On Wed, Sep 16, 2020 at 01:25:39PM -0700, Paul Ramsey wrote:
> >>
> >>> https://docs.google.com/document/d/1TDm2aR4a7O41-soS-25Xog1EdQcjmvKCnKltxjbxOC0/edit#
> >>
> >
> >> * Despite worries, only one file in topology showed any differences. topogeo_addlinestring.sql needs to be looked at by a topology expert, Sandro do you think you could?
> >
> > A quick look suggests this is just a lack of normalization from
> > the output of OverlayNG (did the old overlay normalize internally ?)
>
> No, neither normalizes, it's wasted overhead except in testing. Things just come out of the graphs in different orders.

Well the result seem to be compatible, just different order,
so this case could be threated like the other ones of expecting
different results based on GEOS version.

--strk;
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel