Re: [Jts-topo-suite-user] MCIndexSnapRounder splitting line at each vertex
Brought to you by:
dr_jts
From: Michaël M. <mic...@fr...> - 2012-09-23 15:17:05
|
Hi Martin, Thanks for the test. As I was not satified with the "unchanged" solution, I went on my investigation and found a second issue which seems to be the cause of testColapse1 failure. In MCIndexPointSnapper.HotPixelSnapAction.select() isNodeAdded = hotPixel.addSnappedNode(ss, startIndex); should be changed into isNodeAdded = isNodeAdded || hotPixel.addSnappedNode(ss, startIndex); as we want to test if the hot pixel snaps _*any*_ other segment. Please, tell me if this is correct. During my tests, I used another unit test which is the simplest linestring I found to exhibit the later issue public void testCollapse2() { String[] collapse2 = { "LINESTRING ( 393 175, 391 173, 390 175, 391 174, 391 173 )" }; runRounding(collapse2); } Also there may also be a small bug in SnapRoundingTest.isSnapped(Coordinate v, List lines) not sure if there is a good reason for p0 and p1 to be the same (same index) Thanks for your efforts, Michaël Le 22/09/2012 17:45, Martin Davis a écrit : > Thanks for the reminder, Michael. > > Your fix makes sense, and I tried implementing it, but it makes the > testCollapse1 case in the SnapRoundingTest fail, byproducing non-noded > input. This may have been why I introduced the over-noding in the > first place. I'm not sure why this situation is not getting fully > noded - it's a bit complex (but I think was a real situation I > encountered). Anyway, I'm afraid the SnapRounder will have to remain > unchanged, at least until we can figure out a fix that won't break > this case. > > As for avoiding rounding input data, I'm not sure about this. The > classic snap-rounding algorithm assumes rounded input vertices. I'm > not sure how hard it would be to relax this constraint. > > On Tue, Sep 4, 2012 at 1:10 PM, Michaël Michaud > <mic...@fr... <mailto:mic...@fr...>> wrote: > > Hi Martin >> That does seem a bit odd. Perhaps it's because your example >> linestring has vertices which are very close and sometimes coincident. >> Does the same thing happen for a linestring with longer segments? > Yes, it does not depends on the segment length. > I dived into the code and found that the problem is probably in the > MCIndexPointSnapper.HotPixelSnapAction.select(monotonChain, > startIndex) > > In this method, you skip the test on the segment starting at the > vertex used > to create the HotPixel, but not the segment ending at this same > vertex. > > replacing (line 81) > if (ss == parentEdge && startIndex == vertexIndex) > by > if (ss == parentEdge && (startIndex == vertexIndex || > (startIndex+1) == vertexIndex)) > seems to fix the problem. > > During my tests, I discovered that simple cases could produce > weird results > including invalid geometries *if input is not correctly rounded*. > I think this is > documented. > Just wonder if it would be possible/easy to make MCIndexNoder more > robust > with this kind of data (ex. avoiding moving A to B and B to A in > the same > operation) : > > Here is the example (input in green) > LINESTRING ( 200.0 164.4, 201.3 164.1, 202.4 164.4 ) > LINESTRING ( 199.9 163.1, 201.3 163.8, 202.4 163.1 ) > produce 8 noded SegmentStrings (red on the picture) > 2 of which contain a single point > > > > >> I'm travelling right now so can't investigate this behaviour further >> right now, but will have a look in a week or so. > Have a nice travel and keep the good work > > Michaël > >> On Sun, Sep 2, 2012 at 11:43 AM, Michaël Michaud >> <mic...@fr...> <mailto:mic...@fr...> wrote: >>> Hi Martin, >>> >>> I've been surprised to discover that noding linestrings with >>> MCIndexSnapRounder will not only split my SegmentStrings at >>> intersection points but at each vertex. >>> Is it the normal behaviour ? Any documentation ? >>> >>> Michaël >>> >>> >>> // small script to demonstrate it >>> >>> import com.vividsolutions.jts.noding.snapround.MCIndexSnapRounder; >>> >>> import com.vividsolutions.jts.noding.*; >>> >>> import com.vividsolutions.jts.io.*; >>> >>> g = new WKTReader().read("LINESTRING (1045 1702, 1046 1702, 1048 1702, 1048 >>> 1700, 1046 1700, 1046 1702)"); >>> >>> noder = new MCIndexSnapRounder(new PrecisionModel(1.0)); >>> >>> list = new ArrayList(); >>> >>> list.add(new NodedSegmentString(g.getCoordinates(), null)); >>> >>> noder.computeNodes(list); >>> >>> print(noder.getNodedSubstrings()) >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Jts-topo-suite-user mailing list >>> Jts...@li... <mailto:Jts...@li...> >>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user >>> > > > > > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > > > _______________________________________________ > Jts-topo-suite-user mailing list > Jts...@li... > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user |