[geos-devel] Re: [GEOS] #527: Union and UnaryUnion both fail at correctly node input lines
#527: Union and UnaryUnion both fail at correctly node input lines +--- Reporter: strk| Owner: geos-devel@… Type: defect | Status: new Priority: major | Milestone: 3.3.4 Component: Default | Version: 3.3.3 Severity: Unassigned |Keywords: +--- Comment(by strk): r3608 in 3.3 branch and r3609 in trunk/3.4 also switch unary union over. I'll work on an automated testcase before closing this. -- Ticket URL: http://trac.osgeo.org/geos/ticket/527#comment:11 GEOS http://geos.refractions.net/ GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Re: [GEOS] #527: Union and UnaryUnion both fail at correctly node input lines
#527: Union and UnaryUnion both fail at correctly node input lines +--- Reporter: strk|Owner: geos-devel@… Type: defect | Status: closed Priority: major |Milestone: 3.3.4 Component: Default | Version: 3.3.3 Severity: Unassigned | Resolution: fixed Keywords: | +--- Changes (by strk): * status: new = closed * resolution: = fixed Comment: r3610 / r3611 add a testcase for this (3.3 / trunk) -- Ticket URL: http://trac.osgeo.org/geos/ticket/527#comment:12 GEOS http://geos.refractions.net/ GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Re: [GEOS] #527: Union and UnaryUnion both fail at correctly node input lines
On Mon, Apr 02, 2012 at 10:13:16PM -0700, Martin Davis wrote: JTS uses the FastNodingValidator to check for correctly noded line arrangements. Basically it checks for any interior-interior segment intersections, using indexing to speed things up. And yes, the OGC operation semantics aren't fully capable when it comes to more specific uses like checking noding. That's one reason I introduced the boundary-node rule. The Polygonizer is fine with closed lines (as long as, as always, the linework is FULLY noded). This issue is just one more example of a robustness failure. Do you think the use of a selected Noder might handle such cases better than relying on Union operation to do noding ? It seems to me that GeometryGraph class (used by overlay ops) uses EdgeIntersectionList and friends to perform noding, rather than the noding package. I've been thinking that this specific case of a noding failure could have been resolved by an IteratedNoder (just guessing that the problem is in a splitting node modifying an edge shape to cross another existing edge). --strk; ,--o-. | __/ |Delivering high quality PostGIS 2.0 ! | / 2.0 |http://strk.keybit.net - http://vizzuality.com `-o--' ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Re: [GEOS] #527: Union and UnaryUnion both fail at correctly node input lines
#527: Union and UnaryUnion both fail at correctly node input lines +--- Reporter: strk| Owner: geos-devel@… Type: defect | Status: new Priority: major | Milestone: 3.3.4 Component: Default | Version: 3.3.3 Severity: Unassigned |Keywords: +--- Comment(by strk): Checked: polygonizer is happy with closed components. Wouldn't it be great if we discovered that the noding checker was also fooled by boundary node rule, throwing topology exceptions on perfectly good noding ? (found non-noded intersection etc.etc.) -- Ticket URL: http://trac.osgeo.org/geos/ticket/527#comment:2 GEOS http://geos.refractions.net/ GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Re: [GEOS] #527: Union and UnaryUnion both fail at correctly node input lines
#527: Union and UnaryUnion both fail at correctly node input lines
+---
Reporter: strk| Owner: geos-devel@…
Type: defect | Status: new
Priority: major | Milestone: 3.3.4
Component: Default | Version: 3.3.3
Severity: Unassigned |Keywords:
+---
Comment(by strk):
A second attempt at checking for correct noding: compute intersection
matrix between each pair of lines. Expected outcome: interior/interior
intersection is always false in a correctly noded arrangement.
This confirms UnaryUnion isn't correctly noding:
{{{
with noded as (
select ST_UnaryUnion(
'LINESTRING(1725063 4819121,1725104 4819067,1725060
4819087,1725064.14183882 4819094.70208557,1725064.13656044
4819094.70235069,1725064.14210359 4819094.70227252,1725064.14210362
4819094.70227252,1725064.13656043 4819094.70235069,1725055 4819094,1725055
4819094,1725055 4819094,1725063 4819121)'
) as g ),
dumped as ( select (st_dump(g)).* from noded ),
matrices as ( select a.path as ap, b.path as bp, st_relate(a.geom, b.geom,
2) as im
from dumped a, dumped b where a.path b.path)
select ap, bp, im from matrices where ST_RelateMatch(im, 'T');
ap | bp |im
-+-+---
{1} | {2} | 0F1F00102
{2} | {5} | 1F1F00102
(2 rows)
}}}
So first and second line have puntual interior/interior intersection,
while second and fifth line have lineal interior/interior intersection.
Shouldn't happen, right ?
--
Ticket URL: http://trac.osgeo.org/geos/ticket/527#comment:3
GEOS http://geos.refractions.net/
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Re: [GEOS] #527: Union and UnaryUnion both fail at correctly node input lines
#527: Union and UnaryUnion both fail at correctly node input lines
+---
Reporter: strk| Owner: geos-devel@…
Type: defect | Status: new
Priority: major | Milestone: 3.3.4
Component: Default | Version: 3.3.3
Severity: Unassigned |Keywords:
+---
Comment(by strk):
Further analysis: the first attempt at running the union overlay op fails
the internal noding validator step:
{{{
EdgeNodingValidator found noding invalid: TopologyException: found non-
noded intersection between LINESTRING (1.72506e+06 4.81909e+06,
1.72506e+06 4.81909e+06) and LINESTRING (1.72506e+06 4.81909e+06,
1.72506e+06 4.81909e+06) at 1725064.1365604457 4819094.70235069
}}}
So SnapIfNeededOverlayOp switches on snapping, which seems to pass the
check:
{{{
EdgeNodingValidator accepted the noding
}}}
Now it'd be interesting to see _why_ the internal edge noding validator
passes while our own checking fails it !
--
Ticket URL: http://trac.osgeo.org/geos/ticket/527#comment:5
GEOS http://geos.refractions.net/
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] Re: [GEOS] #527: Union and UnaryUnion both fail at correctly node input lines
#527: Union and UnaryUnion both fail at correctly node input lines
+---
Reporter: strk| Owner: geos-devel@…
Type: defect | Status: new
Priority: major | Milestone: 3.3.4
Component: Default | Version: 3.3.3
Severity: Unassigned |Keywords:
+---
Comment(by strk):
Simplified input still reproducing the bogus noding:
{{{
LINESTRING(
1725063 4819121,
1725064.14183882 4819094.70208557,
1725064.13656044 4819094.70235069,
1725064.14210362 4819094.70227252,
1725064.13656043 4819094.70235069,
1725063 4819121
)
}}}
--
Ticket URL: http://trac.osgeo.org/geos/ticket/527#comment:7
GEOS http://geos.refractions.net/
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite
(JTS).
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Re: [GEOS] #527: Union and UnaryUnion both fail at correctly node input lines
JTS uses the FastNodingValidator to check for correctly noded line arrangements. Basically it checks for any interior-interior segment intersections, using indexing to speed things up. And yes, the OGC operation semantics aren't fully capable when it comes to more specific uses like checking noding. That's one reason I introduced the boundary-node rule. The Polygonizer is fine with closed lines (as long as, as always, the linework is FULLY noded). This issue is just one more example of a robustness failure. On 4/2/2012 2:46 AM, GEOS wrote: #527: Union and UnaryUnion both fail at correctly node input lines +--- Reporter: strk| Owner: geos-devel@… Type: defect | Status: new Priority: major | Milestone: 3.3.4 Component: Default | Version: 3.3.3 Severity: Unassigned |Keywords: +--- Comment(by strk): Uff, ST_IsSimple isn't a good check when it comes to _closed_ lines, in that they have no bounday so the node would be considered as an interior/interior intersection, like here: MULTILINESTRING((0 0, 10 0, 10 10, 0 0), (0 0, -10 0, -10 -10, 0 0)) The boundary node rule is really getting in my way. @mbdavis : how can I check for correct noding ? And is Polygonizer happy with noding which involves closed lines ? /me goes on to try again the polygonizer call with more closed lines. ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1913 / Virus Database: 2114/4909 - Release Date: 04/01/12 ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
