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
