Re: [Jts-topo-suite-user] MCIndexSnapRounder splitting line at each vertex

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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