## jts-topo-suite-user

 [Jts-topo-suite-user] Topological sorting of triangles From: Brian Sanjeewa Rupasinghe - 2013-04-27 08:50:23 Attachments: Message as HTML ```Thanks Stefan, I manged to get the adjacent candidates for each triangle with the method Martin suggested, maintaining edge adjacency list of normalized edges. Best, Brian. ```
 Re: [Jts-topo-suite-user] Topological sorting of triangles From: Brian Sanjeewa Rupasinghe - 2013-04-28 10:16:10 Attachments: Message as HTML ```Hi Stefan, Although I can get the adjacent triangle IDs for each triangle, it is difficult to rearrange the triangulation array according to adjacent sequence. What about the method you suggested? Can't we create the MBR of each triangle, rotate each MBR along X-Y axes, get the lower coordiante pair of each rotated MBR and sort along X-Y....? Brian. On Sat, Apr 27, 2013 at 9:50 AM, Brian Sanjeewa Rupasinghe < jinkabs@...> wrote: > Thanks Stefan, > > I manged to get the adjacent candidates for each triangle with the method > Martin suggested, maintaining edge adjacency list of normalized edges. > > Best, Brian. > ```
 [Jts-topo-suite-user] Overlapping Geometries From: Shahak Nagiel - 2013-05-01 18:23:29 Attachments: Message as HTML ```I've got two multipolygons which--visually and by design--intersect but should not overlap.  (Visualize two adjacent zip codes/cities/counties/countries.)  However, poly1.overlaps(poly2) returns true. So I get the IntersectionMatrix (poly1.relate(poly2)), which yields: 212-111-212.  This confuses me.  The boundary-boundary relationship (1) suggests they share only a one-dimensional boundary.  Indeed, calling poly1.intersection(poly2) yields a multilinestring.  But the interior-interior relationship (2) suggests a two-dimensional overlap, and would explain why poly1.overlaps(poly2) returns true. In a unit test with simpler geometries (two overlapping squares), I find a similar relationship: 212-101-212, the key difference being the boundary-boundary relationship (0 in this case).  This makes sense, since their boundaries cross at (0-dimensional) points, and their overlap is a 2-dimensional polygon.  When I line them up side-by-side, then I get the expected relationship FF2-F11-212 and square1.overlaps(square2) == false.  So, in other words, I'm unable to duplicate the relationship I see with the poly's above. Can anyone make sense of this? Thanks!```
 Re: [Jts-topo-suite-user] Overlapping Geometries From: Martin Davis - 2013-05-01 20:10:59 Attachments: Message as HTML ```In the IM, BB = 1 indicates that there is at some location in the two polygons a place where they have boundary lines that are coincident. But the IM is additive - this does not preclude also having the situation where II = 2 somewhere else. The fact that A.overlaps(B) = true and A.intersection(B) = Line probably indicates that there is a very small discrepancy between vertices along the "shared" boundary. Due to precision issues this can cause the result of predicates to be inconsistent with overlay operations. See D7 here for a further explanation: http://tsusiatsoftware.net/jts/jts-faq/jts-faq.html#D You can confirm this visually in the JTS TestBuilder by using the Magnify Topology feature: http://lin-ear-th-inking.blogspot.ca/2010/08/magnifying-topology-using-jts.html Or even better, post the WKT or WKB of the geometries so I can confirm. On Wed, May 1, 2013 at 11:23 AM, Shahak Nagiel wrote: > I've got two multipolygons which--visually and by design--intersect but > should not overlap. (Visualize two adjacent zip > codes/cities/counties/countries.) However, poly1.overlaps(poly2) returns > true. > > So I get the IntersectionMatrix (poly1.relate(poly2)), which yields: > 212-111-212. This confuses me. The boundary-boundary relationship (1) > suggests they share only a one-dimensional boundary. Indeed, calling > poly1.intersection(poly2) yields a multilinestring. But the > interior-interior relationship (2) suggests a two-dimensional overlap, and > would explain why poly1.overlaps(poly2) returns true. > > In a unit test with simpler geometries (two overlapping squares), I find a > similar relationship: 212-101-212, the key difference being the boundary-boundary > relationship (0 in this case). This makes sense, since their boundaries > cross at (0-dimensional) points, and their overlap is a 2-dimensional > polygon. When I line them up side-by-side, then I get the expected > relationship FF2-F11-212 and square1.overlaps(square2) == false. So, in > other words, I'm unable to duplicate the relationship I see with the poly's > above. > > Can anyone make sense of this? > > Thanks! > > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Jts-topo-suite-user mailing list > Jts-topo-suite-user@... > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user > > ```
 Re: [Jts-topo-suite-user] Overlapping Geometries From: Shahak Nagiel - 2013-05-02 21:00:11 Attachments: Message as HTML ```Good tips.  I'll definitely try to inspect it visually with the TestBuilder (great feature, btw). I'm basically facing the challenge described at http://jts-devel.219725.n2.nabble.com/Simplify-amp-Snap-td2276384.html.  Problem is, I already ran through that basic algorithm and have ended up here; it seemed to have fixed the vast majority of shared vertices, but apparently one (or more) have slipped through (perhaps as a byproduct of the polygonizer process with respect to floating point approximation issues?).  So, I was hoping to find a (relatively easy) solution for snapping adjacent polygons together.   Thanks again. ________________________________ From: Martin Davis To: Cc: "jts-topo-suite-user@..." Sent: Wednesday, May 1, 2013 4:10 PM Subject: Re: [Jts-topo-suite-user] Overlapping Geometries In the IM, BB = 1 indicates that there is at some location in the two polygons a place where they have boundary lines that are coincident.  But the IM is additive - this does not preclude also having the situation where II = 2 somewhere else. The fact that A.overlaps(B) = true and A.intersection(B) = Line probably indicates that there is a very small discrepancy between vertices along the "shared" boundary.  Due to precision issues this can cause the result of predicates to be inconsistent with overlay operations.  See D7 here for a further explanation: http://tsusiatsoftware.net/jts/jts-faq/jts-faq.html#D You can confirm this visually in the JTS TestBuilder by using the Magnify Topology feature:  http://lin-ear-th-inking.blogspot.ca/2010/08/magnifying-topology-using-jts.html Or even better, post the WKT or WKB of the geometries so I can confirm. On Wed, May 1, 2013 at 11:23 AM, Shahak Nagiel wrote: I've got two multipolygons which--visually and by design--intersect but should not overlap.  (Visualize two adjacent zip codes/cities/counties/countries.)  However, poly1.overlaps(poly2) returns true. > > >So I get the IntersectionMatrix (poly1.relate(poly2)), which yields: 212-111-212.  This confuses me.  The boundary-boundary relationship (1) suggests they share only a one-dimensional boundary.  Indeed, calling poly1.intersection(poly2) yields a multilinestring.  But the interior-interior relationship (2) suggests a two-dimensional overlap, and would explain why poly1.overlaps(poly2) returns true. > > >In a unit test with simpler geometries (two overlapping squares), I find a similar relationship: 212-101-212, the key difference being the boundary-boundary relationship (0 in this case).  This makes sense, since their boundaries cross at (0-dimensional) points, and their overlap is a 2-dimensional polygon.  When I line them up side-by-side, then I get the expected relationship FF2-F11-212 and square1.overlaps(square2) == false.  So, in other words, I'm unable to duplicate the relationship I see with the poly's above. > > >Can anyone make sense of this? > > >Thanks! >------------------------------------------------------------------------------ >Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >Get 100% visibility into your production application - at no cost. >Code-level diagnostics for performance bottlenecks with <2% overhead >Download for free and get started troubleshooting in minutes. >http://p.sf.net/sfu/appdyn_d2d_ap1 >_______________________________________________ >Jts-topo-suite-user mailing list >Jts-topo-suite-user@... >https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user > > ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Jts-topo-suite-user mailing list Jts-topo-suite-user@... https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user```
 Re: [Jts-topo-suite-user] Overlapping Geometries From: Martin Davis - 2013-05-02 21:23:10 Attachments: Message as HTML ```Well, as noted in that thread, Simplify-and-Snap is fraught with potential problems. Snapping is a last resort, not a cure-all. So good luck with it! On Thu, May 2, 2013 at 2:00 PM, Shahak Nagiel wrote: > Good tips. I'll definitely try to inspect it visually with the > TestBuilder (great feature, btw). > > I'm basically facing the challenge described at > http://jts-devel.219725.n2.nabble.com/Simplify-amp-Snap-td2276384.html. > Problem is, I already ran through that basic algorithm and have ended up > here; it seemed to have fixed the vast majority of shared vertices, but > apparently one (or more) have slipped through (perhaps as a byproduct of > the polygonizer process with respect to floating point approximation > issues?). So, I was hoping to find a (relatively easy) solution for > snapping adjacent polygons together. > > > ```
 Re: [Jts-topo-suite-user] Overlapping Geometries From: Shahak Nagiel - 2013-05-07 20:00:35 Attachments: Message as HTML ```I finally resolved this issue.  As mentioned, I did follow the general algorithm suggested in the link below (and at http://webmonkeyswithlaserbeams.wordpress.com/2009/03/04/the-sweet-java-topology-suite-part-ii/).  But in at least one case, two of the adjoining polygons were still overlapping. From what I can tell, the issue was some type of floating point rounding issue during the re-polygonization phase.  What I added (after "step 4" in the good guide above) was to "snap" all vertices.  Unfortunately, I couldn't make much progress with the snapping tools in JTS, so I built my own GeometryEditor/CoordinationOperation which reduced the significant digits in each vertex to a reasonable number of decimal places.  After this refinement step, everything works as expected. Thanks. ________________________________ From: Martin Davis To: Shahak Nagiel Cc: "jts-topo-suite-user@..." Sent: Thursday, May 2, 2013 5:23 PM Subject: Re: [Jts-topo-suite-user] Overlapping Geometries Well, as noted in that thread, Simplify-and-Snap is fraught with potential problems.  Snapping is a last resort, not a cure-all.  So good luck with it! On Thu, May 2, 2013 at 2:00 PM, Shahak Nagiel wrote: Good tips.  I'll definitely try to inspect it visually with the TestBuilder (great feature, btw). > > >I'm basically facing the challenge described at http://jts-devel.219725.n2.nabble.com/Simplify-amp-Snap-td2276384.html.  Problem is, I already ran through that basic algorithm and have ended up here; it seemed to have fixed the vast majority of shared vertices, but apparently one (or more) have slipped through (perhaps as a byproduct of the polygonizer process with respect to floating point approximation issues?).  So, I was hoping to find a (relatively easy) solution for snapping adjacent polygons together.   > > > >```