From: Brian Sanjeewa Rupasinghe <jinkabs@gm...>  20130427 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. 
From: Brian Sanjeewa Rupasinghe <jinkabs@gm...>  20130428 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 XY axes, get the lower coordiante pair of each rotated MBR and sort along XY....? 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. > 
From: Shahak Nagiel <snagiel@ya...>  20130501 18:23:29
Attachments:
Message as HTML

I've got two multipolygons whichvisually and by designintersect 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: 212111212. This confuses me. The boundaryboundary relationship (1) suggests they share only a onedimensional boundary. Indeed, calling poly1.intersection(poly2) yields a multilinestring. But the interiorinterior relationship (2) suggests a twodimensional 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: 212101212, the key difference being the boundaryboundary relationship (0 in this case). This makes sense, since their boundaries cross at (0dimensional) points, and their overlap is a 2dimensional polygon. When I line them up sidebyside, then I get the expected relationship FF2F11212 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! 
From: Martin Davis <mtnclimb@gm...>  20130501 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/jtsfaq/jtsfaq.html#D You can confirm this visually in the JTS TestBuilder by using the Magnify Topology feature: http://linearthinking.blogspot.ca/2010/08/magnifyingtopologyusingjts.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 <snagiel@...> wrote: > I've got two multipolygons whichvisually and by designintersect 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: > 212111212. This confuses me. The boundaryboundary relationship (1) > suggests they share only a onedimensional boundary. Indeed, calling > poly1.intersection(poly2) yields a multilinestring. But the > interiorinterior relationship (2) suggests a twodimensional 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: 212101212, the key difference being the boundaryboundary > relationship (0 in this case). This makes sense, since their boundaries > cross at (0dimensional) points, and their overlap is a 2dimensional > polygon. When I line them up sidebyside, then I get the expected > relationship FF2F11212 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. > Codelevel diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > 
From: Shahak Nagiel <snagiel@ya...>  20130502 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://jtsdevel.219725.n2.nabble.com/SimplifyampSnaptd2276384.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 <mtnclimb@...> To: Cc: "jtstoposuiteuser@..." <jtstoposuiteuser@...> Sent: Wednesday, May 1, 2013 4:10 PM Subject: Re: [Jtstoposuiteuser] 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/jtsfaq/jtsfaq.html#D You can confirm this visually in the JTS TestBuilder by using the Magnify Topology feature: http://linearthinking.blogspot.ca/2010/08/magnifyingtopologyusingjts.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 <snagiel@...> wrote: I've got two multipolygons whichvisually and by designintersect 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: 212111212. This confuses me. The boundaryboundary relationship (1) suggests they share only a onedimensional boundary. Indeed, calling poly1.intersection(poly2) yields a multilinestring. But the interiorinterior relationship (2) suggests a twodimensional 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: 212101212, the key difference being the boundaryboundary relationship (0 in this case). This makes sense, since their boundaries cross at (0dimensional) points, and their overlap is a 2dimensional polygon. When I line them up sidebyside, then I get the expected relationship FF2F11212 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. >Codelevel diagnostics for performance bottlenecks with <2% overhead >Download for free and get started troubleshooting in minutes. >http://p.sf.net/sfu/appdyn_d2d_ap1 >_______________________________________________ >Jtstoposuiteuser mailing list >Jtstoposuiteuser@... >https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > >  Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application  at no cost. Codelevel diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Jtstoposuiteuser mailing list Jtstoposuiteuser@... https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser 
From: Martin Davis <mtnclimb@gm...>  20130502 21:23:10
Attachments:
Message as HTML

Well, as noted in that thread, SimplifyandSnap is fraught with potential problems. Snapping is a last resort, not a cureall. So good luck with it! On Thu, May 2, 2013 at 2:00 PM, Shahak Nagiel <snagiel@...> 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://jtsdevel.219725.n2.nabble.com/SimplifyampSnaptd2276384.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. > > > 
From: Shahak Nagiel <snagiel@ya...>  20130507 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/thesweetjavatopologysuitepartii/). 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 repolygonization 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 <mtnclimb@...> To: Shahak Nagiel <snagiel@...> Cc: "jtstoposuiteuser@..." <jtstoposuiteuser@...> Sent: Thursday, May 2, 2013 5:23 PM Subject: Re: [Jtstoposuiteuser] Overlapping Geometries Well, as noted in that thread, SimplifyandSnap is fraught with potential problems. Snapping is a last resort, not a cureall. So good luck with it! On Thu, May 2, 2013 at 2:00 PM, Shahak Nagiel <snagiel@...> 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://jtsdevel.219725.n2.nabble.com/SimplifyampSnaptd2276384.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. > > > > 