OverlayNG for Testing

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

OverlayNG for Testing

Paul Ramsey
OK, as requested it is now possible to test OverlayNG using C clients.

https://github.com/libgeos/geos/commit/c6774a6a48b2

For autotools, use

  --enable-overlayng

For cmake, add

  -DDISABLE_OVERLAYNG=OFF

No guarantees, this is completely untested, except insofar as it all still compiles in the default state (which is overlayng off).

The goal, of course, is to get to a point before release where the default state can be overlayng on.

Some things we already know don't work:

- 3D! GEOS uniquely has supported adding in Z coordinates to introduced coordinates, and that code hasn't been added to JTS (and thus overlayng). How this will affect existing expectations for 3D output is unknown, but it's sure to be broken in some way.
- Union on linestrings! OverlayNG extracts maximal length linestrings from the unioned graph. Old overlay extracted minimal length linestrings. This change is probably "for the best" but it's a change which might impact existing logic.

ATB,

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

Re: OverlayNG for Testing

Regina Obe
Are these expected to fail?

344: Files: 1
344: Tests: 143
344: Failed: 0
344: Succeeded: 143
344/344 Test #344: validate-TestRelatePP ....................................   Passed    0.01 sec

92% tests passed, 28 tests failed out of 344

Total Test time (real) =  12.45 sec

The following tests FAILED:
         46 - unit-capi-GEOSGeom_setPrecision (Failed)
         52 - unit-capi-GEOSIntersection (Failed)
         57 - unit-capi-GEOSMakeValid (Failed)
         79 - unit-capi-GEOSUnaryUnion (Failed)
        148 - unit-operation-geounion-CascadedPolygonUnion (Failed)
        152 - unit-operation-linemerge-LineMerger (Failed)
        154 - unit-operation-overlay-OverlayOpUnion (Failed)
        200 - general-TestFunctionAA (Failed)
        201 - general-TestFunctionAAPrec (Failed)
        202 - general-TestFunctionLA (Failed)
        203 - general-TestFunctionLAPrec (Failed)
        204 - general-TestFunctionLL (Failed)
        205 - general-TestFunctionLLPrec (Failed)
        207 - general-TestFunctionPL (Failed)
        234 - general-TestUnaryUnion (Failed)
        246 - issue-issue-geos-350 (Failed)
        248 - issue-issue-geos-358 (Failed)
        249 - issue-issue-geos-360 (Failed)
        254 - issue-issue-geos-459 (Failed)
        255 - issue-issue-geos-488 (Failed)
        256 - issue-issue-geos-527 (Failed)
        259 - issue-issue-geos-586 (Failed)
        260 - issue-issue-geos-599 (Failed)
        262 - issue-issue-geos-615 (Failed)
        264 - issue-issue-geos-837 (Failed)
        265 - issue-issue-geos-838 (Failed)
        288 - misc-split (Failed)
        292 - robust-TestRobustOverlayFixed (Failed)
Errors while running CTest

> -----Original Message-----
> From: geos-devel [mailto:[hidden email]] On Behalf
> Of Paul Ramsey
> Sent: Wednesday, July 29, 2020 3:54 PM
> To: GEOS Development List <[hidden email]>
> Subject: [geos-devel] OverlayNG for Testing
>
> OK, as requested it is now possible to test OverlayNG using C clients.
>
> https://github.com/libgeos/geos/commit/c6774a6a48b2
>
> For autotools, use
>
>   --enable-overlayng
>
> For cmake, add
>
>   -DDISABLE_OVERLAYNG=OFF
>
> No guarantees, this is completely untested, except insofar as it all still
> compiles in the default state (which is overlayng off).
>
> The goal, of course, is to get to a point before release where the default
> state can be overlayng on.
>
> Some things we already know don't work:
>
> - 3D! GEOS uniquely has supported adding in Z coordinates to introduced
> coordinates, and that code hasn't been added to JTS (and thus overlayng).
> How this will affect existing expectations for 3D output is unknown, but it's
> sure to be broken in some way.
> - Union on linestrings! OverlayNG extracts maximal length linestrings from
> the unioned graph. Old overlay extracted minimal length linestrings. This
> change is probably "for the best" but it's a change which might impact
> existing logic.
>
> ATB,
>
> P
> _______________________________________________
> 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: OverlayNG for Testing

Paul Ramsey
Yes, I expect lots of internal failures, in addition to failures in external programs.
I'm looking at the unit test failures right now.
Some of them are representational, because the units tests don't bother to normalize before comparing geometries (since the overlay code consistently gave the same results).
Some of them are true behaviour changes. Hopefully many will be easily fixable.
Some of them will end up being deep conundrums.
If all you're going to do us run regression tests and tell me they fail... I'm doing that anyways. Be more creative.

P

> On Jul 29, 2020, at 1:42 PM, Regina Obe <[hidden email]> wrote:
>
> Are these expected to fail?
>
> 344: Files: 1
> 344: Tests: 143
> 344: Failed: 0
> 344: Succeeded: 143
> 344/344 Test #344: validate-TestRelatePP ....................................   Passed    0.01 sec
>
> 92% tests passed, 28 tests failed out of 344
>
> Total Test time (real) =  12.45 sec
>
> The following tests FAILED:
>         46 - unit-capi-GEOSGeom_setPrecision (Failed)
>         52 - unit-capi-GEOSIntersection (Failed)
>         57 - unit-capi-GEOSMakeValid (Failed)
>         79 - unit-capi-GEOSUnaryUnion (Failed)
>        148 - unit-operation-geounion-CascadedPolygonUnion (Failed)
>        152 - unit-operation-linemerge-LineMerger (Failed)
>        154 - unit-operation-overlay-OverlayOpUnion (Failed)
>        200 - general-TestFunctionAA (Failed)
>        201 - general-TestFunctionAAPrec (Failed)
>        202 - general-TestFunctionLA (Failed)
>        203 - general-TestFunctionLAPrec (Failed)
>        204 - general-TestFunctionLL (Failed)
>        205 - general-TestFunctionLLPrec (Failed)
>        207 - general-TestFunctionPL (Failed)
>        234 - general-TestUnaryUnion (Failed)
>        246 - issue-issue-geos-350 (Failed)
>        248 - issue-issue-geos-358 (Failed)
>        249 - issue-issue-geos-360 (Failed)
>        254 - issue-issue-geos-459 (Failed)
>        255 - issue-issue-geos-488 (Failed)
>        256 - issue-issue-geos-527 (Failed)
>        259 - issue-issue-geos-586 (Failed)
>        260 - issue-issue-geos-599 (Failed)
>        262 - issue-issue-geos-615 (Failed)
>        264 - issue-issue-geos-837 (Failed)
>        265 - issue-issue-geos-838 (Failed)
>        288 - misc-split (Failed)
>        292 - robust-TestRobustOverlayFixed (Failed)
> Errors while running CTest
>
>> -----Original Message-----
>> From: geos-devel [mailto:[hidden email]] On Behalf
>> Of Paul Ramsey
>> Sent: Wednesday, July 29, 2020 3:54 PM
>> To: GEOS Development List <[hidden email]>
>> Subject: [geos-devel] OverlayNG for Testing
>>
>> OK, as requested it is now possible to test OverlayNG using C clients.
>>
>> https://github.com/libgeos/geos/commit/c6774a6a48b2
>>
>> For autotools, use
>>
>>  --enable-overlayng
>>
>> For cmake, add
>>
>>  -DDISABLE_OVERLAYNG=OFF
>>
>> No guarantees, this is completely untested, except insofar as it all still
>> compiles in the default state (which is overlayng off).
>>
>> The goal, of course, is to get to a point before release where the default
>> state can be overlayng on.
>>
>> Some things we already know don't work:
>>
>> - 3D! GEOS uniquely has supported adding in Z coordinates to introduced
>> coordinates, and that code hasn't been added to JTS (and thus overlayng).
>> How this will affect existing expectations for 3D output is unknown, but it's
>> sure to be broken in some way.
>> - Union on linestrings! OverlayNG extracts maximal length linestrings from
>> the unioned graph. Old overlay extracted minimal length linestrings. This
>> change is probably "for the best" but it's a change which might impact
>> existing logic.
>>
>> ATB,
>>
>> P
>> _______________________________________________
>> 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: OverlayNG for Testing

Martin Davis-3
In reply to this post by Paul Ramsey
On Wed, Jul 29, 2020 at 12:53 PM Paul Ramsey <[hidden email]> wrote:

- 3D! GEOS uniquely has supported adding in Z coordinates to introduced coordinates, and that code hasn't been added to JTS (and thus overlayng). How this will affect existing expectations for 3D output is unknown, but it's sure to be broken in some way.
- Union on linestrings! OverlayNG extracts maximal length linestrings from the unioned graph. Old overlay extracted minimal length linestrings. This change is probably "for the best" but it's a change which might impact existing logic.

Another behavioural change is that now overlay operations do not return mixed-dimension results.  Instead, a homogeneous geometry containing only the highest dimension resultants is returned.

So for example, if two polygons intersect in an area and along an edge, the new overlay will only return the area resultant.  The old overlay returned a GEOMETRYCOLLECTION containing both a polygon and a line.  

Or, if two polygons intersect along an edge and at a point, the new result is a LineString for the shared edge.  The old overlay returns a GC ccntaining a line and a point.

The old behaviour seemed like a pain, since most (all?) uses were only interested in the highest dimension resultants.  And since GeometryCollections cannot be processed by overlay ops or spatial predicates, it made chaining together operations painful.

What are people's thoughts on this?  It is probably possible to build in the old behaviour (with a bit of coding effort), and make it the default path.  But I think the new behaviour is preferable and more sensible.
 

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

Re: OverlayNG for Testing

Regina Obe
In reply to this post by Paul Ramsey
That was just to make sure I'm on the same page.  Don't worry I'll be very creative.

> -----Original Message-----
> From: geos-devel [mailto:[hidden email]] On Behalf
> Of Paul Ramsey
> Sent: Wednesday, July 29, 2020 4:51 PM
> To: GEOS Development List <[hidden email]>
> Subject: Re: [geos-devel] OverlayNG for Testing
>
> Yes, I expect lots of internal failures, in addition to failures in external
> programs.
> I'm looking at the unit test failures right now.
> Some of them are representational, because the units tests don't bother to
> normalize before comparing geometries (since the overlay code consistently
> gave the same results).
> Some of them are true behaviour changes. Hopefully many will be easily
> fixable.
> Some of them will end up being deep conundrums.
> If all you're going to do us run regression tests and tell me they fail... I'm
> doing that anyways. Be more creative.
>
> P
>
> > On Jul 29, 2020, at 1:42 PM, Regina Obe <[hidden email]> wrote:
> >
> > Are these expected to fail?
> >
> > 344: Files: 1
> > 344: Tests: 143
> > 344: Failed: 0
> > 344: Succeeded: 143
> > 344/344 Test #344: validate-TestRelatePP ....................................
> Passed    0.01 sec
> >
> > 92% tests passed, 28 tests failed out of 344
> >
> > Total Test time (real) =  12.45 sec
> >
> > The following tests FAILED:
> >         46 - unit-capi-GEOSGeom_setPrecision (Failed)
> >         52 - unit-capi-GEOSIntersection (Failed)
> >         57 - unit-capi-GEOSMakeValid (Failed)
> >         79 - unit-capi-GEOSUnaryUnion (Failed)
> >        148 - unit-operation-geounion-CascadedPolygonUnion (Failed)
> >        152 - unit-operation-linemerge-LineMerger (Failed)
> >        154 - unit-operation-overlay-OverlayOpUnion (Failed)
> >        200 - general-TestFunctionAA (Failed)
> >        201 - general-TestFunctionAAPrec (Failed)
> >        202 - general-TestFunctionLA (Failed)
> >        203 - general-TestFunctionLAPrec (Failed)
> >        204 - general-TestFunctionLL (Failed)
> >        205 - general-TestFunctionLLPrec (Failed)
> >        207 - general-TestFunctionPL (Failed)
> >        234 - general-TestUnaryUnion (Failed)
> >        246 - issue-issue-geos-350 (Failed)
> >        248 - issue-issue-geos-358 (Failed)
> >        249 - issue-issue-geos-360 (Failed)
> >        254 - issue-issue-geos-459 (Failed)
> >        255 - issue-issue-geos-488 (Failed)
> >        256 - issue-issue-geos-527 (Failed)
> >        259 - issue-issue-geos-586 (Failed)
> >        260 - issue-issue-geos-599 (Failed)
> >        262 - issue-issue-geos-615 (Failed)
> >        264 - issue-issue-geos-837 (Failed)
> >        265 - issue-issue-geos-838 (Failed)
> >        288 - misc-split (Failed)
> >        292 - robust-TestRobustOverlayFixed (Failed) Errors while
> > running CTest
> >
> >> -----Original Message-----
> >> From: geos-devel [mailto:[hidden email]] On
> >> Behalf Of Paul Ramsey
> >> Sent: Wednesday, July 29, 2020 3:54 PM
> >> To: GEOS Development List <[hidden email]>
> >> Subject: [geos-devel] OverlayNG for Testing
> >>
> >> OK, as requested it is now possible to test OverlayNG using C clients.
> >>
> >> https://github.com/libgeos/geos/commit/c6774a6a48b2
> >>
> >> For autotools, use
> >>
> >>  --enable-overlayng
> >>
> >> For cmake, add
> >>
> >>  -DDISABLE_OVERLAYNG=OFF
> >>
> >> No guarantees, this is completely untested, except insofar as it all
> >> still compiles in the default state (which is overlayng off).
> >>
> >> The goal, of course, is to get to a point before release where the
> >> default state can be overlayng on.
> >>
> >> Some things we already know don't work:
> >>
> >> - 3D! GEOS uniquely has supported adding in Z coordinates to
> >> introduced coordinates, and that code hasn't been added to JTS (and thus
> overlayng).
> >> How this will affect existing expectations for 3D output is unknown,
> >> but it's sure to be broken in some way.
> >> - Union on linestrings! OverlayNG extracts maximal length linestrings
> >> from the unioned graph. Old overlay extracted minimal length
> >> linestrings. This change is probably "for the best" but it's a change
> >> which might impact existing logic.
> >>
> >> ATB,
> >>
> >> P
> >> _______________________________________________
> >> 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

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

Re: OverlayNG for Testing

Paul Ramsey
In reply to this post by Paul Ramsey


> Some things we already know don't work:
>
> - 3D! GEOS uniquely has supported adding in Z coordinates to introduced coordinates, and that code hasn't been added to JTS (and thus overlayng). How this will affect existing expectations for 3D output is unknown, but it's sure to be broken in some way.
> - Union on linestrings! OverlayNG extracts maximal length linestrings from the unioned graph. Old overlay extracted minimal length linestrings. This change is probably "for the best" but it's a change which might impact existing logic.

In general linestring output.

select st_astext(st_difference('LINESTRING(-11.1111111 70,70 -11.1111111)'::geometry, 'LINESTRING (20.1 90, 20.1 -90)'::geometry));

                         st_astext                        
-----------------------------------------------------------
 LINESTRING(-11.1111111 70,20.1 38.7888889,70 -11.1111111)

The old overlay would output a MULTILINESTRING. This has broken PostGIS old split hack, which depends on the output of a collection to carry out splitting.


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

Re: OverlayNG for Testing

Sandro Santilli-4
In reply to this post by Martin Davis-3
On Wed, Jul 29, 2020 at 02:08:59PM -0700, Martin Davis wrote:

> Another behavioural change is that now overlay operations do not return
> mixed-dimension results.  Instead, a homogeneous geometry containing only
> the highest dimension resultants is returned.

ST_MakeValid in PostGIS expects the old behavior, as the funders of it
insisted in "not loosing any vertex" (so not throwing away anything).

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

Re: OverlayNG for Testing

Martin Davis-3


On Thu, Jul 30, 2020 at 9:08 AM Sandro Santilli <[hidden email]> wrote:
On Wed, Jul 29, 2020 at 02:08:59PM -0700, Martin Davis wrote:

> Another behavioural change is that now overlay operations do not return
> mixed-dimension results.  Instead, a homogeneous geometry containing only
> the highest dimension resultants is returned.

ST_MakeValid in PostGIS expects the old behavior, as the funders of it
insisted in "not loosing any vertex" (so not throwing away anything).

How does ST_MakeValid use the overlay operations? 

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

Re: OverlayNG for Testing

Martin Davis-3
In reply to this post by Martin Davis-3
A clarification on the semantics of output from OverlayNG.  Some operations CAN return heterogeneous (mixed-dimension) outputs in some situations.  

The exact semantics are:

  • Results are always valid geometries. In particular, result MultiPolygons are valid.
  • Repeated vertices are removed.
  • Linear results are merged node-to-node (e.g. are of maximal length).
  • Polygon edges which collapse completely due to rounding are not output.
  • The intersection operation produces a homogeneous result. The result contains the components of highest dimension in the intersection. (For instance, the intersection of a Polygon and a LineStringmight produce a Point result.)
  • The difference operation produces a homogeneous result. The result dimension is that of the left-hand operand.
  • The union and symmetric difference operations may produce a heterogeneous result if the inputs are of mixed dimension 
  • Homogeneous results are output as Multi geometries.
  • Heterogeneous results are in the form of a GeometryCollection containing a set of atomic geometries. This provides backwards compatibility with the original JTS overlay implementation. (However, this loses the information that the polygonal results have valid MultiPolygon topology.)
  • Empty results are atomic EMPTY geometries of dimension appropriate to the operation.


On Wed, Jul 29, 2020 at 2:08 PM Martin Davis <[hidden email]> wrote:
On Wed, Jul 29, 2020 at 12:53 PM Paul Ramsey <[hidden email]> wrote:

- 3D! GEOS uniquely has supported adding in Z coordinates to introduced coordinates, and that code hasn't been added to JTS (and thus overlayng). How this will affect existing expectations for 3D output is unknown, but it's sure to be broken in some way.
- Union on linestrings! OverlayNG extracts maximal length linestrings from the unioned graph. Old overlay extracted minimal length linestrings. This change is probably "for the best" but it's a change which might impact existing logic.

Another behavioural change is that now overlay operations do not return mixed-dimension results.  Instead, a homogeneous geometry containing only the highest dimension resultants is returned.

So for example, if two polygons intersect in an area and along an edge, the new overlay will only return the area resultant.  The old overlay returned a GEOMETRYCOLLECTION containing both a polygon and a line.  

Or, if two polygons intersect along an edge and at a point, the new result is a LineString for the shared edge.  The old overlay returns a GC ccntaining a line and a point.

The old behaviour seemed like a pain, since most (all?) uses were only interested in the highest dimension resultants.  And since GeometryCollections cannot be processed by overlay ops or spatial predicates, it made chaining together operations painful.

What are people's thoughts on this?  It is probably possible to build in the old behaviour (with a bit of coding effort), and make it the default path.  But I think the new behaviour is preferable and more sensible.
 

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

Re: OverlayNG for Testing

Sandro Santilli-4
In reply to this post by Martin Davis-3
On Thu, Jul 30, 2020 at 09:51:05AM -0700, Martin Davis wrote:

> On Thu, Jul 30, 2020 at 9:08 AM Sandro Santilli <[hidden email]> wrote:
>
> > On Wed, Jul 29, 2020 at 02:08:59PM -0700, Martin Davis wrote:
> >
> > > Another behavioural change is that now overlay operations do not return
> > > mixed-dimension results.  Instead, a homogeneous geometry containing only
> > > the highest dimension resultants is returned.
> >
> > ST_MakeValid in PostGIS expects the old behavior, as the funders of it
> > insisted in "not loosing any vertex" (so not throwing away anything).
>
> How does ST_MakeValid use the overlay operations?

In many ways, but a quick look at the code seems to suggest it should
not suffer from the behavioural change in that the "cut edges" seem to
be extracted on the side (to be double-checked).

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

Re: OverlayNG for Testing

Paul Ramsey


> On Jul 30, 2020, at 11:29 AM, Sandro Santilli <[hidden email]> wrote:
>
> On Thu, Jul 30, 2020 at 09:51:05AM -0700, Martin Davis wrote:
>> On Thu, Jul 30, 2020 at 9:08 AM Sandro Santilli <[hidden email]> wrote:
>>
>>> On Wed, Jul 29, 2020 at 02:08:59PM -0700, Martin Davis wrote:
>>>
>>>> Another behavioural change is that now overlay operations do not return
>>>> mixed-dimension results.  Instead, a homogeneous geometry containing only
>>>> the highest dimension resultants is returned.
>>>
>>> ST_MakeValid in PostGIS expects the old behavior, as the funders of it
>>> insisted in "not loosing any vertex" (so not throwing away anything).
>>
>> How does ST_MakeValid use the overlay operations?
>
> In many ways, but a quick look at the code seems to suggest it should
> not suffer from the behavioural change in that the "cut edges" seem to
> be extracted on the side (to be double-checked).

Just to be sure, I've pointed all the overlay ops in MakeValid at the old overlay code. Eventually MakeValid will be superceded by something that works off the overlay graph directly. Until then we'll just ensure it works as before.

P

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

Re: OverlayNG for Testing

Daniel Baston
In reply to this post by Martin Davis-3
What are people's thoughts on this?  It is probably possible to build in the old behaviour (with a bit of coding effort), and make it the default path.  But I think the new behaviour is preferable and more sensible.

This behavior seems confusing to me, and I'm struggling to tell if it's just because I'm used to the old behavior. But it did occur to me that this introduces an inconsistency between the predicates and overlay functions wherein A and B may intersect at a point outside the intersection of A and B.

It's also easy enough for a user to remove the unwanted components of the result but quite difficult to generate lower-dimension components that were not included in the result.

Dan

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

Re: OverlayNG for Testing

Nyall Dawson
On Fri, 31 Jul 2020 at 10:30, Daniel Baston <[hidden email]> wrote:
>>
>> What are people's thoughts on this?  It is probably possible to build in the old behaviour (with a bit of coding effort), and make it the default path.  But I think the new behaviour is preferable and more sensible.
>
>
> This behavior seems confusing to me, and I'm struggling to tell if it's just because I'm used to the old behavior. But it did occur to me that this introduces an inconsistency between the predicates and overlay functions wherein A and B may intersect at a point outside the intersection of A and B.

+1 This potentially opens the door for many hidden issues.

> It's also easy enough for a user to remove the unwanted components of the result

... and every downstream project/user already had handling for this in place.

(and then just because this email sounds too negative -- this is
seriously exciting stuff, and I'm really happy to see all this hard
work land! Big kudos on all your efforts here)

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

Re: OverlayNG for Testing

Paul Ramsey


> On Jul 30, 2020, at 5:55 PM, Nyall Dawson <[hidden email]> wrote:
>
> On Fri, 31 Jul 2020 at 10:30, Daniel Baston <[hidden email]> wrote:
>>>
>>> What are people's thoughts on this?  It is probably possible to build in the old behaviour (with a bit of coding effort), and make it the default path.  But I think the new behaviour is preferable and more sensible.
>>
>>
>> This behavior seems confusing to me, and I'm struggling to tell if it's just because I'm used to the old behavior. But it did occur to me that this introduces an inconsistency between the predicates and overlay functions wherein A and B may intersect at a point outside the intersection of A and B.
>
> +1 This potentially opens the door for many hidden issues.
>
>> It's also easy enough for a user to remove the unwanted components of the result
>
> ... and every downstream project/user already had handling for this in place.
>
> (and then just because this email sounds too negative -- this is
> seriously exciting stuff, and I'm really happy to see all this hard
> work land! Big kudos on all your efforts here)

No, this is great, and thank you Dan for articulating a more compelling reason to keep the old behaviour than "it's always been that way". I had not thought of consistency with the predicates and, yeah, that's really a good thing to have.

I just thought while at the gym that ST_CollectionExtract() could be made a smidge smarter to also have a one-argument variant that figures out the highest dimensionality component and return that, so getting the "nicer" behaviour would be just one extra function call, and involve no magic numbers.

On a similar note, Martin has recovered the old behaviour for linstrings in overlays so we should be able to be back-compatible there too. As with the collections, there's an existing mechanism to get "nicer" behaviour already, the ST_Linemerge function.

My hope is that, if we do these pieces to get old semantics, we will just be left with adding in the Z handling and be very very close to original semantics, enough so that we can stamp it 3.9 instead of 4.0. I love backwards compatibility on principle.

P

>
> Nyall
> _______________________________________________
> 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: OverlayNG for Testing

Martin Davis-3
In reply to this post by Daniel Baston
On Thu, Jul 30, 2020 at 5:30 PM Daniel Baston <[hidden email]> wrote:
What are people's thoughts on this?  It is probably possible to build in the old behaviour (with a bit of coding effort), and make it the default path.  But I think the new behaviour is preferable and more sensible.

This behavior seems confusing to me, and I'm struggling to tell if it's just because I'm used to the old behavior.

FWIW, It seems like simpler behaviour to me.  And I think that's evidenced by clients needing to introduce special code to strip out the unwanted components.  
 
But it did occur to me that this introduces an inconsistency between the predicates and overlay functions wherein A and B may intersect at a point outside the intersection of A and B.

There isn't absolute consistency between the predicates and overlay functions anyway, due to the snapping heuristics in overlay, and the lack of a tolerance in the predicates.  But agreed, this would move "further" from consistency.  Although I'm not sure that really matters - if consistency cannot be guaranteed (which it can't), then clients should not rely on it being true.  (I am hoping to implement a new approach to computing predicates, which supports a tolerance.  But this still won't provide full consistency, and I'm not sure that can ever be provided given heuristics, finite precision, and robustness issues)   

It's also easy enough for a user to remove the unwanted components of the result but quite difficult to generate lower-dimension components that were not included in the result.

That's a good point.  And that is often the motivation for design decisions in JTS - do the hard things, if it's easy to derive simpler things.

Actually there are two aspects to this semantic.  There are of course situations where geometries "natively" intersect in multiple dimension components.  And then there are situations where topology collapse occurs during noding (e.g. where a narrow area is turned into a line), and that "line" intersects the other geometry.  The old behaviour was to return collapses as lines (or points), if they intersected.  That is more consistent with the predicates as noted above.

Unfortunately I'm not sure how easy these behaviours are to implement with the new OverlayNG codebase.  Something to investigate, I guess.


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

Re: OverlayNG for Testing

Sandro Santilli-4
In reply to this post by Paul Ramsey
On Thu, Jul 30, 2020 at 06:04:11PM -0700, Paul Ramsey wrote:

> On a similar note, Martin has recovered the old behaviour for linstrings in overlays so we should be able to be back-compatible there too. As with the collections, there's an existing mechanism to get "nicer" behaviour already, the ST_Linemerge function.
>
> My hope is that, if we do these pieces to get old semantics, we will just be left with adding in the Z handling and be very very close to original semantics, enough so that we can stamp it 3.9 instead of 4.0. I love backwards compatibility on principle.

Do you have an updated list of tasks to complete to get backward
compatibility in place ? I probably have the possibility to work
on some of them.

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

Re: OverlayNG for Testing

Paul Ramsey
Here's a spreadsheet...

https://docs.google.com/spreadsheets/d/15Jk5cNuYdxPPA9fXIxCreRJNlkQZjc2KdYaX-odW8So/edit#gid=936876052

It's probably not complete, but it's got the big entries...

> On Aug 6, 2020, at 1:08 PM, Sandro Santilli <[hidden email]> wrote:
>
> On Thu, Jul 30, 2020 at 06:04:11PM -0700, Paul Ramsey wrote:
>
>> On a similar note, Martin has recovered the old behaviour for linstrings in overlays so we should be able to be back-compatible there too. As with the collections, there's an existing mechanism to get "nicer" behaviour already, the ST_Linemerge function.
>>
>> My hope is that, if we do these pieces to get old semantics, we will just be left with adding in the Z handling and be very very close to original semantics, enough so that we can stamp it 3.9 instead of 4.0. I love backwards compatibility on principle.
>
> Do you have an updated list of tasks to complete to get backward
> compatibility in place ? I probably have the possibility to work
> on some of them.
>
> --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: OverlayNG for Testing

rmrodriguez
Hi there,

> It's probably not complete, but it's got the big entries...

I reported a couple of issues on GEOS trac. Is that good or is there a
more convenient place to track OverlayNG issues?

On Thu, Aug 6, 2020 at 10:48 PM Paul Ramsey <[hidden email]> wrote:

>
> Here's a spreadsheet...
>
> https://docs.google.com/spreadsheets/d/15Jk5cNuYdxPPA9fXIxCreRJNlkQZjc2KdYaX-odW8So/edit#gid=936876052
>
> It's probably not complete, but it's got the big entries...
>
> > On Aug 6, 2020, at 1:08 PM, Sandro Santilli <[hidden email]> wrote:
> >
> > On Thu, Jul 30, 2020 at 06:04:11PM -0700, Paul Ramsey wrote:
> >
> >> On a similar note, Martin has recovered the old behaviour for linstrings in overlays so we should be able to be back-compatible there too. As with the collections, there's an existing mechanism to get "nicer" behaviour already, the ST_Linemerge function.
> >>
> >> My hope is that, if we do these pieces to get old semantics, we will just be left with adding in the Z handling and be very very close to original semantics, enough so that we can stamp it 3.9 instead of 4.0. I love backwards compatibility on principle.
> >
> > Do you have an updated list of tasks to complete to get backward
> > compatibility in place ? I probably have the possibility to work
> > on some of them.
> >
> > --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



--
Raúl Marín Rodríguez
carto.com
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: OverlayNG for Testing

Paul Ramsey
In reply to this post by Paul Ramsey
So, with the last two commits

https://github.com/libgeos/geos/commit/aaafcce2

We (haha, mostly Martin) have restored the old Linstring.Union() behaviour (node-to-node lines extracted from graph) and the old Geometry.Intersection() behaviour (all dimensional components extracted from graph into GeometryCollection).

This should substantially reduce the number of regression issues when building with the NG overlay turned on. As before I haven't actually tested this myself yet, it's the end of the day, but I have high hopes.

We still have the known regression that Z values aren't going to be added/preserved in 2d/3d and 3d/3d overlays.

Thank you Andrew Bell for the fixes to master to pass MSVC builds now too.

Next week, continued testing on regressions from me. Martin is away.

P.


On Thu, Aug 6, 2020 at 1:47 PM Paul Ramsey <[hidden email]> wrote:
Here's a spreadsheet...

https://docs.google.com/spreadsheets/d/15Jk5cNuYdxPPA9fXIxCreRJNlkQZjc2KdYaX-odW8So/edit#gid=936876052

It's probably not complete, but it's got the big entries...

> On Aug 6, 2020, at 1:08 PM, Sandro Santilli <[hidden email]> wrote:
>
> On Thu, Jul 30, 2020 at 06:04:11PM -0700, Paul Ramsey wrote:
>
>> On a similar note, Martin has recovered the old behaviour for linstrings in overlays so we should be able to be back-compatible there too. As with the collections, there's an existing mechanism to get "nicer" behaviour already, the ST_Linemerge function.
>>
>> My hope is that, if we do these pieces to get old semantics, we will just be left with adding in the Z handling and be very very close to original semantics, enough so that we can stamp it 3.9 instead of 4.0. I love backwards compatibility on principle.
>
> Do you have an updated list of tasks to complete to get backward
> compatibility in place ? I probably have the possibility to work
> on some of them.
>
> --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