Thread: [Jts-topo-suite-user] MCIndexSnapRounder splitting line at each vertex
Brought to you by:
dr_jts
From: Michaël M. <mic...@fr...> - 2012-09-02 18:43:24
|
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())* |
From: Martin D. <mtn...@gm...> - 2012-09-03 04:46:03
|
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? I'm travelling right now so can't investigate this behaviour further right now, but will have a look in a week or so. On Sun, Sep 2, 2012 at 11:43 AM, Michaël Michaud <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... > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user > |
From: Michaël M. <mic...@fr...> - 2012-09-04 20:10:28
|
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...> 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... >> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user >> > |
From: Michaël M. <mic...@fr...> - 2012-09-22 11:30:59
|
Hi Martin, Let me know if the proposed fix is correct. Note that I've all the time, but as I did not get feedback and I know you was travelling when I sent this mail, I'm worried that the problem may miss the opportunity to be fixed before 1.13 release, Thanks, Michaël >> 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...> 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... >>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user >>> > > > > ------------------------------------------------------------------------------ > 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... > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user |
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 |
From: Simon G. <si...@sp...> - 2012-10-02 08:05:35
|
Folks, I'm sure this must be possible but looking at the API I can't see the woods for the trees. I want to add the intersection points LINESTRING (0.0 1.0, 4.0 1.0) LINESTRING (1.0 4.0, 1.0 0.0) LINESTRING (2.0 0.0, 2.0 3.0) LINESTRING (3.0 2.0, 0.0 2.0)On Mon, 24 Sep 2012 01:16:47 +1000, Michaël Michaud <mic...@fr...> wrote: > Hi Martin, > > Thanks for the test. > As I was not satified with the "unchanged" solution, I went on my investigationand 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 intoisNodeAdded = 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 inSnapRoundingTest.isSnapped(Coordinate v, List lines) > not sure if there is a good reason for p0 and p1 to be thesame (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...> 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 theMCIndexPointSnapper.HotPixelSnapAction.select(monotonChain, startIndex) >>> >>> In this method, you skip the test on the segment starting at the vertex usedto 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 resultsincluding invalid geometries if input is not correctly rounded. I think this isdocumented. >>> Just wonder if it would be possible/easy to make MCIndexNoder more robustwith this kind of data (ex. avoiding moving A to B and B to A in the sameoperation) : >>> >>> 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...> 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... >>>>> 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 > -- Holder of "2011 Oracle Spatial Excellence Award for Education and Research." SpatialDB Advice and Design, Solutions Architecture and Programming, Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, FME, Radius Topology and Studio Specialist. 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia. Website: www.spatialdbadvisor.com Email: si...@sp... Voice: +61 362 396397 Mobile: +61 418 396391 Skype: sggreener Longitude: 147.20515 (147° 12' 18" E) Latitude: -43.01530 (43° 00' 55" S) GeoHash: r22em9r98wg NAC:W80CK 7SWP3 |
From: Martin D. <mtn...@gm...> - 2012-09-23 15:37:35
|
Great sleuthing, Michael! Those fixes all look good, so I'm rolling them into SVN. Thanks for helping to make JTS better. Martin On Sun, Sep 23, 2012 at 8:16 AM, Michaël Michaud <mic...@fr...>wrote: > 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) > > |
From: Sandro S. <st...@ke...> - 2012-09-24 08:16:46
|
On Sun, Sep 23, 2012 at 08:37:29AM -0700, Martin Davis wrote: > Great sleuthing, Michael! Those fixes all look good, so I'm rolling them > into SVN. > > Thanks for helping to make JTS better. Looking forward to port the fix into GEOS. Please let me know when it's ready in JTS. Thanks a lot to both of you ! --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html -- what comes below this line is just spam, dont bother scrolling... still here ? |
From: Martin D. <mtn...@te...> - 2012-09-24 14:26:01
|
It's in SVN, a couple of revs back. On 9/24/2012 1:16 AM, Sandro Santilli wrote: > On Sun, Sep 23, 2012 at 08:37:29AM -0700, Martin Davis wrote: >> Great sleuthing, Michael! Those fixes all look good, so I'm rolling them >> into SVN. >> >> Thanks for helping to make JTS better. > Looking forward to port the fix into GEOS. > Please let me know when it's ready in JTS. Thanks a lot to both of you ! > > --strk; > > () Free GIS & Flash consultant/developer > /\ http://strk.keybit.net/services.html > > -- > > what comes below this line is just spam, dont bother scrolling... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > still here ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > 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... > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2221 / Virus Database: 2441/5287 - Release Date: 09/23/12 > > |
From: Simon G. <si...@sp...> - 2012-10-02 08:06:44
|
Folks, I'm sure this must be possible but looking at the API I can't see the woods for the trees. I want to process the following set of lines and add to each one the intersection points it has with any other line. LINESTRING (0.0 1.0, 4.0 1.0) LINESTRING (1.0 4.0, 1.0 0.0) LINESTRING (2.0 0.0, 2.0 3.0) LINESTRING (3.0 2.0, 0.0 2.0) Can someone point me to the required functionality or sample code? regards Simon -- Holder of "2011 Oracle Spatial Excellence Award for Education and Research." SpatialDB Advice and Design, Solutions Architecture and Programming, Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, FME, Radius Topology and Studio Specialist. 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia. Website: www.spatialdbadvisor.com Email: si...@sp... Voice: +61 362 396397 Mobile: +61 418 396391 Skype: sggreener Longitude: 147.20515 (147° 12' 18" E) Latitude: -43.01530 (43° 00' 55" S) GeoHash: r22em9r98wg NAC:W80CK 7SWP3 |
From: Martin D. <mtn...@te...> - 2012-10-03 03:01:04
|
There's a couple of ways to do this, depending on how high or low level you want to get. One way is to create a MultiLineString with the lines, and then execute the union() method on it. That will create a fully-noded MultiLineString. The other way is to use one of the Noder subclasses in the noding package. MCIndexNoder is probably the one you should use here. For an example of use, have a look at the NodingFunctions.MCIndexNoding method (in SVN). Martin On 10/2/2012 1:06 AM, Simon Greener wrote: > Folks, > > I'm sure this must be possible but looking at the API I can't see the > woods for the trees. > > I want to process the following set of lines and add to each one the > intersection points it has with any other line. > > LINESTRING (0.0 1.0, 4.0 1.0) > LINESTRING (1.0 4.0, 1.0 0.0) > LINESTRING (2.0 0.0, 2.0 3.0) > LINESTRING (3.0 2.0, 0.0 2.0) > > Can someone point me to the required functionality or sample code? > > |
From: Simon G. <si...@sp...> - 2012-10-03 06:36:32
|
Martin, Thank you, excellent. regards Simon On Wed, 03 Oct 2012 13:00:52 +1000, Martin Davis <mtn...@te...> wrote: > There's a couple of ways to do this, depending on how high or low level you want to get. > > One way is to create a MultiLineString with the lines, and then execute the union() method on it. That will create a fully-noded MultiLineString. > > The other way is to use one of the Noder subclasses in the noding package. MCIndexNoder is probably the one you should use here. For an >example of use, have a look at the NodingFunctions.MCIndexNoding method (in SVN). > > Martin > > On 10/2/2012 1:06 AM, Simon Greener wrote: >> Folks, >> >> I'm sure this must be possible but looking at the API I can't see the woods for the trees. >> >> I want to process the following set of lines and add to each one the intersection points it has with any other line. >> >> LINESTRING (0.0 1.0, 4.0 1.0) >> LINESTRING (1.0 4.0, 1.0 0.0) >> LINESTRING (2.0 0.0, 2.0 3.0) >> LINESTRING (3.0 2.0, 0.0 2.0) >> >> Can someone point me to the required functionality or sample code? >> >> > -- Holder of "2011 Oracle Spatial Excellence Award for Education and Research." SpatialDB Advice and Design, Solutions Architecture and Programming, Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, FME, Radius Topology and Studio Specialist. 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia. Website: www.spatialdbadvisor.com Email: si...@sp... Voice: +61 362 396397 Mobile: +61 418 396391 Skype: sggreener Longitude: 147.20515 (147° 12' 18" E) Latitude: -43.01530 (43° 00' 55" S) GeoHash: r22em9r98wg NAC:W80CK 7SWP3 |