### Email Archive: jts-topo-suite-user (read-only)

 2009: 2010: 2011: 2012: 2013: Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov (3) Dec Jan (30) Feb (41) Mar (69) Apr (131) May (67) Jun (24) Jul (28) Aug (52) Sep (9) Oct (24) Nov (36) Dec (24) Jan (20) Feb (53) Mar (31) Apr (74) May (71) Jun (51) Jul (28) Aug (91) Sep (72) Oct (46) Nov (90) Dec (38) Jan (80) Feb (77) Mar (98) Apr (78) May (56) Jun (85) Jul (53) Aug (87) Sep (74) Oct (67) Nov (85) Dec (66) Jan (50) Feb (34) Mar (45) Apr (36) May (22) Jun (10) Jul (30) Aug (39) Sep (25) Oct (11) Nov (64) Dec (35)
S M T W T F S
1 2

3 4 5 6 7 8 9
(3)   (1)
10 11 12 13 14 15 16
(1)   (2)   (3) (9) (2)
17 18 19 20 21 22 23
(2)
24 25 26 27 28 29 30
(1)
31

 jts-topo-suite-user Nested Flat Threaded Ultimate Show 25 Show 50 Show 75 Show 100
 [Jts-topo-suite-user] Strange polygon case From: Jose C. Martinez-Llario - 2010-10-22 13:55 ```Hi Martin, I have two polygons like: A - POLYGON ((280 320, 260 20, 540 20, 540 320, 280 320)) B - POLYGON ((740 300, 440 160, 720 40, 740 300)) If I do: C = A.Diference(B) D = C.Intersection(B) D should be empty?..I guess no because the boundary of polygon B can not be subtracted from A but the result is not what i was expecting to get: LINESTRING (540 206.66666666666666, 440 160) it is just half of the intersection boundary!. If I change the polygons A and B with this ones (snapping each other and inserting the new vertexes): POLYGON ((280 320, 260 20, 540 20, 540 117.14285714285714, 540 206.66666666666666, 540 320, 280 320)) POLYGON ((740 300, 540 206.66666666666666, 440 160, 540 117.14285714285714, 720 40, 740 300)) then i get the expected result: MULTILINESTRING ((540 206.66666666666666, 440 160), (440 160, 540 117.14285714285714)) Umm...just wanted to ask if it is normal or not. It makes me think about the snapping tolerance we talked several months ago: http://sourceforge.net/mailarchive/message.php?msg_name=4C534B34.5090003%40cgf.upv.es Did you have time to develop or have you though about some funciontality to snap polygons? Thanks in advance. Jose ```

 Re: [Jts-topo-suite-user] Strange polygon case From: Martin Davis - 2010-10-22 18:48 Attachments: Message as HTML ```Jose, What you're seeing is expected behaviour. As you probably know, this is due to the effects of using finite precision floating point to evaluate line intersections and overlay operations. In general, overlay operations do not fully obey the axioms of set-theoretic topology. So it's not always possible to conclude that: A.diiference(B).intersection(B) is contained in B.boundary() As you point out, one way to move closer to (or possibly fully meet?) the set-theoretic model is to always snap arguments together (using some tolerance distance). Something similar to this has been researched Guting et al with their realm-based spatial algebra: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.121.1159 I have spent some time thinking about this, and there is some code in JTS which implements some of the functionality required. (I.e the snap-rounding algorithms in the snapround package. Currently this only produces noded linework, however - maintaining polyonal topology is a task to be done.) The supported PrecisionModel comes into play here too - overlay operations on snapped geometry probably need to be evaluated in a PrecisionModel which matches the snapping grid. These ideas haven't been pushed forward to a final implementation mostly due to lack of time, funding, and a truly inspiring use case. Martin On Fri, Oct 22, 2010 at 6:55 AM, Jose C. Martinez-Llario < jomarlla@...> wrote: > Hi Martin, > I have two polygons like: > > A - POLYGON ((280 320, 260 20, 540 20, 540 320, 280 320)) > B - POLYGON ((740 300, 440 160, 720 40, 740 300)) > > If I do: > C = A.Diference(B) > D = C.Intersection(B) > > D should be empty?..I guess no because the boundary of polygon B can not > be subtracted from A but the result is not what i was expecting to get: > > LINESTRING (540 206.66666666666666, 440 160) > it is just half of the intersection boundary!. > > If I change the polygons A and B with this ones (snapping each other and > inserting the new vertexes): > POLYGON ((280 320, 260 20, 540 20, 540 117.14285714285714, 540 > 206.66666666666666, 540 320, 280 320)) > POLYGON ((740 300, 540 206.66666666666666, 440 160, 540 > 117.14285714285714, 720 40, 740 300)) > > then i get the expected result: > MULTILINESTRING ((540 206.66666666666666, 440 160), (440 160, 540 > 117.14285714285714)) > > Umm...just wanted to ask if it is normal or not. It makes me think about > the snapping tolerance we talked several months ago: > > http://sourceforge.net/mailarchive/message.php?msg_name=4C534B34.5090003%40cgf.upv.es > Did you have time to develop or have you though about some > funciontality to snap polygons? > > > Thanks in advance. > Jose > > > > ------------------------------------------------------------------------------ > Nokia and AT&T present the 2010 Calling All Innovators-North America > contest > Create new apps & games for the Nokia N8 for consumers in U.S. and Canada > \$10 million total in prizes - \$4M cash, 500 devices, nearly \$6M in > marketing > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store > http://p.sf.net/sfu/nokia-dev2dev > _______________________________________________ > 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] Strange polygon case From: Jose Carlos Martínez Llario - 2010-10-24 13:27 Attachments: Message as HTML ```Hi Martin, thanks for the answer. Its a pity these thoughs havent been pushed forward. Really hope JTS can find funding. JTS is a very important part of many open source geospatial projects. I would say that most the java projects use JTS. Hope some of these important projects understand how important is JTS and what this project deserves. Unfortunately, JASPA at this moment does not have any funding and I just develop it because i like it. I am thinking in writing some proposal to get an official research project from my University or the Spanish ministry to get some funding. I will have JTS in my mind too. Maybe we could apply for some international research projects announcements. Regards, Jose On 22/10/2010 20:48, Martin Davis wrote: > Jose, > > What you're seeing is expected behaviour. As you probably know, this > is due to the effects of using finite precision floating point to > evaluate line intersections and overlay operations. > > In general, overlay operations do not fully obey the axioms of > set-theoretic topology. So it's not always possible to conclude that: > > A.diiference(B).intersection(B) is contained in B.boundary() > > As you point out, one way to move closer to (or possibly fully meet?) > the set-theoretic model is to always snap arguments together (using > some tolerance distance). Something similar to this has been > researched Guting et al with their realm-based spatial algebra: > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.121.1159 > > I have spent some time thinking about this, and there is some code in > JTS which implements some of the functionality required. (I.e the > snap-rounding algorithms in the snapround package. Currently this > only produces noded linework, however - maintaining polyonal topology > is a task to be done.) The supported PrecisionModel comes into play > here too - overlay operations on snapped geometry probably need to be > evaluated in a PrecisionModel which matches the snapping grid. > > These ideas haven't been pushed forward to a final implementation > mostly due to lack of time, funding, and a truly inspiring use case. > > Martin > > > > > On Fri, Oct 22, 2010 at 6:55 AM, Jose C. Martinez-Llario > > wrote: > > Hi Martin, > I have two polygons like: > > A - POLYGON ((280 320, 260 20, 540 20, 540 320, 280 320)) > B - POLYGON ((740 300, 440 160, 720 40, 740 300)) > > If I do: > C = A.Diference(B) > D = C.Intersection(B) > > D should be empty?..I guess no because the boundary of polygon B > can not > be subtracted from A but the result is not what i was expecting to > get: > > LINESTRING (540 206.66666666666666, 440 160) > it is just half of the intersection boundary!. > > If I change the polygons A and B with this ones (snapping each > other and > inserting the new vertexes): > POLYGON ((280 320, 260 20, 540 20, 540 117.14285714285714, 540 > 206.66666666666666, 540 320, 280 320)) > POLYGON ((740 300, 540 206.66666666666666, 440 160, 540 > 117.14285714285714, 720 40, 740 300)) > > then i get the expected result: > MULTILINESTRING ((540 206.66666666666666, 440 160), (440 160, 540 > 117.14285714285714)) > > Umm...just wanted to ask if it is normal or not. It makes me think > about > the snapping tolerance we talked several months ago: > http://sourceforge.net/mailarchive/message.php?msg_name=4C534B34.5090003%40cgf.upv.es > Did you have time to develop or have you though about some > funciontality to snap polygons? > > > Thanks in advance. > Jose > > > ------------------------------------------------------------------------------ > Nokia and AT&T present the 2010 Calling All Innovators-North > America contest > Create new apps & games for the Nokia N8 for consumers in U.S. > and Canada > \$10 million total in prizes - \$4M cash, 500 devices, nearly \$6M in > marketing > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi > Store > http://p.sf.net/sfu/nokia-dev2dev > _______________________________________________ > Jts-topo-suite-user mailing list > Jts-topo-suite-user@... > > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user > > ```

 [Jts-topo-suite-user] Semantic for empty geometries From: Michaël Michaud - 2010-10-10 14:46 ```Hi Martin, I try to fix some problems with empty shape reading/writing for OpenJUMP shapefile driver and realize that the semantic for empty geometries is very confusing. Each geometry type supports empty geometries. I cannot see good reason for that and would be glad to learn if there are some use cases. But, this is not my main point. In JTS, two empty geometries having the "same geometry type" are not equal as demonstrated by this line of code : geometryFactory.createMultiPolygon(new Polygon[0]).equals(geometryFactory.createMultiPolygon(new Polygon[0]))); -> returns false With JTS builder, relate function of the two empty multipolygons return "FFFFFFFF2". Thus, this result is consistent with the de-9IM definition of equals (T*F**FFF*) and with its litteral definition taken from javadoc : "The two geometries have at least one point in common, and no point of either geometry lies in the exterior of the other geometry." Is this really the expected behaviour, and is there some theoretical to explain this result ? Thanks for clarification Michaël ```

 Re: [Jts-topo-suite-user] Semantic for empty geometries From: Martin Davis - 2010-10-12 16:30 ```Now, I agree that it doesn't seem very reasonable that two empty POLYGONs do not compare as equal. So there's a conflict between having "equals" exactly reflect SFS semantics, and between having it behave "reasonably" (according to some opinion). But there's another reasonable question to ask: should ALL empty geomtries of any type test as equal? After all, from a topological point of view they are all just the empy set. So it's not clear to me exactly what the most *desireable* semantics for empty geometries are. As in most JTS design questions, I chose to follow the SFS semantics, since I thought that would be most consistent, and since it is really the only open standard which is available. So what does this mean for the user? If you are concerned about testing empty geometries for equality, you need to introduce a check specifically design to implement the logic you require. This isn't too hard to do. (As an analogy which should be familiar to Java programmers, empty geometries are similar to Double.NaN. You have to test explicitly for it's presence, since Double.NaN != Double.NaN by definition) And perhaps I should also add this information to the Javadoc, for clarity. Are there any other semantic issues with empty geometry handling that you're running into? Martin On 10/10/2010 7:46 AM, Michaël Michaud wrote: > Hi Martin, > > I try to fix some problems with empty shape reading/writing for OpenJUMP > shapefile driver and realize that the semantic for empty geometries is > very confusing. > Each geometry type supports empty geometries. I cannot see good reason > for that and would be glad to learn if there are some use cases. But, > this is not my main point. > > In JTS, two empty geometries having the "same geometry type" are not > equal as demonstrated by this line of code : > > geometryFactory.createMultiPolygon(new > Polygon[0]).equals(geometryFactory.createMultiPolygon(new Polygon[0]))); > -> returns false > > With JTS builder, relate function of the two empty multipolygons return > "FFFFFFFF2". > Thus, this result is consistent with the de-9IM definition of equals > (T*F**FFF*) and with its litteral definition taken from javadoc : > "The two geometries have at least one point in common, > and no point of either geometry lies in the exterior of the other > geometry." > > Is this really the expected behaviour, and is there some theoretical to > explain this result ? > > Thanks for clarification > > Michaël > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Jts-topo-suite-user mailing list > Jts-topo-suite-user@... > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ```

 Re: [Jts-topo-suite-user] Semantic for empty geometries From: Martin Davis - 2010-10-12 16:40 ```The most important part of my previous emai got lost! Here's the way the post should have read: Michael, My understanding of the DE-9IM matrix is that the relate result "FFFFFFFF2" does NOT match the equals pattern "T*F**FFF*" (due to the fact that the I/I entry "F" does not match the pattern's "T"). So in fact the current semantics for handling empty geometries under "equals" is correct. This is also consistent with the verbal definition for equals - since empty geometries do not contain any points, they cannot have any points in common. Now, I agree that it doesn't seem very reasonable that two empty POLYGONs do not compare as equal. So there's a conflict between having "equals" exactly reflect SFS semantics, and between having it behave "reasonably" (according to some opinion). But there's another reasonable question to ask: should ALL empty geomtries of any type test as equal? After all, from a topological point of view they are all just the empy set. So it's not clear to me exactly what the most *desireable* semantics for empty geometries are. As in most JTS design questions, I chose to follow the SFS semantics, since I thought that would be most consistent, and since it is really the only open standard which is available. So what does this mean for the user? If you are concerned about testing empty geometries for equality, you need to introduce a check specifically design to implement the logic you require. This isn't too hard to do. (As an analogy which should be familiar to Java programmers, empty geometries are similar to Double.NaN. You have to test explicitly for it's presence, since Double.NaN != Double.NaN by definition) And perhaps I should also add this information to the Javadoc, for clarity. Are there any other semantic issues with empty geometry handling that you're running into? Martin -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ```

 [Jts-topo-suite-user] Semantic for empty geometries From: Michaël Michaud - 2010-10-16 15:30 ```Hi Martin, Sorry, I just discover your answer in the mailing list. There is something I don't understand about the list usage. I usualy receive all Jts-topo-suite-user messages, but did not receive your answer about this subject. Also I could not find a way to "answer" from the archive which is read-only. Anyway, thanks for explanations. I still can't see why SFS did this choice, and I see many reasons why a special and unique EmptyGeometry constant would have been more consistent, but I understand your choice to stick to this widely used standard which incidentally has plenty of advantages. Interesting comparison to Double.NaN May be there is a theoretical reason for empty set of for NaN to consider that they differ from anything including themself... I thought non equality of empty geometries had to do with a bug preventing empty geometry deletion in OpenJUMP, but it was not exactly the case (however, it had to do with empty geometry usage in the edit transaction process). Now I wonder if there is a place for a static boolean equalOrEmpty(Geometry,Geometry) method in JTS, but maybe a comment in equals method definition is sufficient (I think it could make the situation clearer, even if definition already implies that empty geometries are not equal) Michaël ```

 Re: [Jts-topo-suite-user] Semantic for empty geometries From: Jose Carlos Martínez Llario - 2010-10-16 16:21 ```Hi, I think its complicated to manage empty geometries specially for final users. If we talk about spatial databases its is even more complicated for final users because empty geometries throw 'weird' errors like geometry type and geometry dimension violation constraints, and sometimes one can not know when a spatial operation can return an empty geometry. In jaspa, I took the decision to treat empty geometries as they were null geometries. I filter empty geometries in the wkb reader/writers. It worked ok for me. I think the other approach would be to have empty geometries in all types, still geometry dimension problem can affect final users though. regards, jose On 16/10/2010 17:30, Michaël Michaud wrote: > Hi Martin, > > Sorry, I just discover your answer in the mailing list. > There is something I don't understand about the list usage. > I usualy receive all Jts-topo-suite-user messages, but did not receive > your answer about this subject. > Also I could not find a way to "answer" from the archive which is read-only. > > Anyway, thanks for explanations. I still can't see why SFS did this > choice, and I see many reasons why a special and unique EmptyGeometry > constant would have been more consistent, but I understand your choice > to stick to this widely used standard which incidentally has plenty of > advantages. > > Interesting comparison to Double.NaN > May be there is a theoretical reason for empty set of for NaN to > consider that they differ from anything including themself... > > I thought non equality of empty geometries had to do with a bug > preventing empty geometry deletion in OpenJUMP, but it was not exactly > the case (however, it had to do with empty geometry usage in the edit > transaction process). > > Now I wonder if there is a place for a static boolean > equalOrEmpty(Geometry,Geometry) method in JTS, but maybe a comment in > equals method definition is sufficient (I think it could make the > situation clearer, even if definition already implies that empty > geometries are not equal) > > Michaël > > > > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > Jts-topo-suite-user mailing list > Jts-topo-suite-user@... > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user ```

 [Jts-topo-suite-user] Talking about performance From: Jose C. Martinez-Llario - 2010-10-15 15:59 ```Talking about performance, In JASPA I changed the WKB Readers/writers to use java arrays instead of streams. According to some bechmark I did, using byte arrays is around double faster. Now I would like to try java.nio, did you already try it out? Jose ```

 Re: [Jts-topo-suite-user] Talking about performance From: Martin Davis - 2010-10-15 16:03 ```Nope, haven't tried java.nio. Can you provide more details on how you used arrays? Is this design able to read data in a streaming fashion? Is the approach compatible with the stream-based code? Jose C. Martinez-Llario wrote: > Talking about performance, In JASPA I changed the WKB Readers/writers > to use java arrays instead of streams. According to some bechmark I did, > using byte arrays is around double faster. > > Now I would like to try java.nio, did you already try it out? > Jose > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > 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] Talking about performance From: Jose C. Martinez-Llario - 2010-10-15 16:15 ```Sorry I had to sacrified streaming fashion and compatibility. Just, I used byte[] without wrapping using streams. Faster yes but less powefull. If the RDBM backend used streams then I would have to get the streaming approach back. So far, PLJAVA with postgres and H2 do not manage streams. Dont know about Oracle in java. If you want more details, in the JASPA source code I put the WKB/WKT/EWKB/EWKT from JTS. I did more changes about managing SRID, m coordinate, etc. When I try java.nio I will let you know the results. Regards, Jose El 15/10/2010 18:02, Martin Davis escribió: > Nope, haven't tried java.nio. > > Can you provide more details on how you used arrays? Is this design > able to read data in a streaming fashion? Is the approach compatible > with the stream-based code? > > Jose C. Martinez-Llario wrote: >> Talking about performance, In JASPA I changed the WKB >> Readers/writers to use java arrays instead of streams. According to >> some bechmark I did, using byte arrays is around double faster. >> >> Now I would like to try java.nio, did you already try it out? >> Jose >> >> ------------------------------------------------------------------------------ >> >> Download new Adobe(R) Flash(R) Builder(TM) 4 >> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly >> Flex(R) Builder(TM)) enable the development of rich applications that >> run >> across multiple browsers and platforms. Download your free trials today! >> http://p.sf.net/sfu/adobe-dev2dev >> _______________________________________________ >> Jts-topo-suite-user mailing list >> Jts-topo-suite-user@... >> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user >> ```

 [Jts-topo-suite-user] GeometryComponentFilter From: Jose C. Martinez-Llario - 2010-10-15 11:04 ```Hi Martin, I read in the documentation that GeometryComponentFilter does not visit Polygons themselves inside a multipolygon. But when I use it with a Multipolygon with two polygons (each one with one hole) I got the following gometries visited: Visited: com.vividsolutions.jts.geom.MultiPolygon Visited: com.vividsolutions.jts.geom.Polygon Visited: com.vividsolutions.jts.geom.LinearRing Visited: com.vividsolutions.jts.geom.Polygon Visited: com.vividsolutions.jts.geom.LinearRing Visited: com.vividsolutions.jts.geom.Polygon Visited: com.vividsolutions.jts.geom.LinearRing Visited: com.vividsolutions.jts.geom.Polygon Visited: com.vividsolutions.jts.geom.LinearRing This is the expected behaviour or I missundertood the documentation? Thanx, Jose ```

 Re: [Jts-topo-suite-user] GeometryComponentFilter From: Martin Davis - 2010-10-15 15:48 ```Yes, the doc is wrong. *Every* Geometry and component is visited by GeometryComponentVisitor. You can easily filter out the atomic components if that's what you want. At this point I should probably just change the documentation, rather than the behaviour. Thoughts? Jose C. Martinez-Llario wrote: > Hi Martin, > I read in the documentation that GeometryComponentFilter does not visit > Polygons themselves inside a multipolygon. But when I use it with a > Multipolygon with two polygons (each one with one hole) I got the > following gometries visited: > > Visited: com.vividsolutions.jts.geom.MultiPolygon > Visited: com.vividsolutions.jts.geom.Polygon > Visited: com.vividsolutions.jts.geom.LinearRing > Visited: com.vividsolutions.jts.geom.Polygon > Visited: com.vividsolutions.jts.geom.LinearRing > Visited: com.vividsolutions.jts.geom.Polygon > Visited: com.vividsolutions.jts.geom.LinearRing > Visited: com.vividsolutions.jts.geom.Polygon > Visited: com.vividsolutions.jts.geom.LinearRing > > This is the expected behaviour or I missundertood the documentation? > Thanx, > Jose > > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > 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] GeometryComponentFilter From: Jose C. Martinez-Llario - 2010-10-15 15:53 ```That is what i was guessing. I like how GeometryComponentFilter works until now. I agree that just changing the docs is enough. El 15/10/2010 17:47, Martin Davis escribió: > Yes, the doc is wrong. *Every* Geometry and component is visited by > GeometryComponentVisitor. You can easily filter out the atomic > components if that's what you want. > > At this point I should probably just change the documentation, rather > than the behaviour. Thoughts? > > Jose C. Martinez-Llario wrote: >> Hi Martin, >> I read in the documentation that GeometryComponentFilter does not >> visit Polygons themselves inside a multipolygon. But when I use it >> with a Multipolygon with two polygons (each one with one hole) I got >> the following gometries visited: >> >> Visited: com.vividsolutions.jts.geom.MultiPolygon >> Visited: com.vividsolutions.jts.geom.Polygon >> Visited: com.vividsolutions.jts.geom.LinearRing >> Visited: com.vividsolutions.jts.geom.Polygon >> Visited: com.vividsolutions.jts.geom.LinearRing >> Visited: com.vividsolutions.jts.geom.Polygon >> Visited: com.vividsolutions.jts.geom.LinearRing >> Visited: com.vividsolutions.jts.geom.Polygon >> Visited: com.vividsolutions.jts.geom.LinearRing >> >> This is the expected behaviour or I missundertood the documentation? >> Thanx, >> Jose >> >> >> ------------------------------------------------------------------------------ >> >> Download new Adobe(R) Flash(R) Builder(TM) 4 >> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly >> Flex(R) Builder(TM)) enable the development of rich applications that >> run >> across multiple browsers and platforms. Download your free trials today! >> http://p.sf.net/sfu/adobe-dev2dev >> _______________________________________________ >> 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] how to find repeated points From: Jose C. Martinez-Llario - 2010-10-15 10:01 ```Martin, as you sugested me I did some bechmark about finding repeated poitns. Here is the result. Some conclusions about the results in my computer: < 25 points brute force shows little bit better result than hashset > 50 points hashset is the best one Dont use brute force for more then 100 points. kdtree shows good performance but around 4 times slower than hashset in most cases. Didnt check the java memory..in that sense brute force should be the best one. cheers, Jose Method 0 is HashSet Method 1 is KdTree Method 2 is Brute force Base Points: 9 Repeated Points: 1 Iterations: 5000000 Method: 0 start... Method: 0 end... Average time one iteration: 8.474E-4ms Method: 1 start... Method: 1 end... Average time one iteration: 0.001378ms Method: 2 start... Method: 2 end... Average time one iteration: 4.396E-4ms Base Points: 22 Repeated Points: 3 Iterations: 1000000 Method: 0 start... Method: 0 end... Average time one iteration: 0.002135ms Method: 1 start... Method: 1 end... Average time one iteration: 0.005063ms Method: 2 start... Method: 2 end... Average time one iteration: 0.002506ms Base Points: 45 Repeated Points: 5 Iterations: 500000 Method: 0 start... Method: 0 end... Average time one iteration: 0.004596ms Method: 1 start... Method: 1 end... Average time one iteration: 0.012818ms Method: 2 start... Method: 2 end... Average time one iteration: 0.009758ms Base Points: 90 Repeated Points: 10 Iterations: 50000 Method: 0 start... Method: 0 end... Average time one iteration: 0.00974ms Method: 1 start... Method: 1 end... Average time one iteration: 0.02988ms Method: 2 start... Method: 2 end... Average time one iteration: 0.03828ms Base Points: 450 Repeated Points: 50 Iterations: 5000 Method: 0 start... Method: 0 end... Average time one iteration: 0.0582ms Method: 1 start... Method: 1 end... Average time one iteration: 0.22ms Method: 2 start... Method: 2 end... Average time one iteration: 0.942ms Base Points: 900 Repeated Points: 100 Iterations: 500 Method: 0 start... Method: 0 end... Average time one iteration: 0.114ms Method: 1 start... Method: 1 end... Average time one iteration: 0.476ms Method: 2 start... Method: 2 end... Average time one iteration: 3.74ms Base Points: 4500 Repeated Points: 500 Iterations: 20 Method: 0 start... Method: 0 end... Average time one iteration: 0.55ms Method: 1 start... Method: 1 end... Average time one iteration: 3.95ms Method: 2 start... Method: 2 end... Average time one iteration: 94.25ms main function: public static void repeatedPoints (Coordinate[] coors, int type) { int n = 0; if (type == 0) { HashSet hashCoor = new HashSet (); int prevSize = 0; int newSize = 0; for (Coordinate c: coors) { hashCoor.add(c); newSize = hashCoor.size(); if (newSize == prevSize) { //This one is repeated n++; } prevSize = newSize; } //it will work but i want to know witch points are repeated //n = coors.length - hashCoor.size(); } else if (type == 1) { n = 0; KdTree kdtree = new KdTree(); KdNode node; for (Coordinate c: coors) { node = kdtree.insert(c); if (node.getCount() > 1) { //This one is repeated n++; } } } else if (type == 2) { //Brute force n = 0; int np = coors.length; for (int i = 0; i < np - 1; i++) for (int j = i+1; j < np; j++) { if (coors[i].equals(coors[j])) { n++; } } } else Assert.shouldNeverReachHere(); //System.out.println ("\t\tTotal points: " + coors.length + " Repeated points: " + n); } ```

 Re: [Jts-topo-suite-user] how to find repeated points From: Martin Davis - 2010-10-15 15:47 ```Good to have it confirmed that HashSet/Map is the fastest way of testing for point equality. It's worth noting that KdTree is still useful, since it supports range queries, as well as an "equality tolerance". Jose C. Martinez-Llario wrote: > Martin, as you sugested me I did some bechmark about finding repeated > poitns. > Here is the result. > > Some conclusions about the results in my computer: > > < 25 points brute force shows little bit better result than hashset > > 50 points hashset is the best one > > Dont use brute force for more then 100 points. > kdtree shows good performance but around 4 times slower than hashset in > most cases. > > > Didnt check the java memory..in that sense brute force should be the > best one. > > cheers, > Jose > > > > Method 0 is HashSet > Method 1 is KdTree > Method 2 is Brute force > Base Points: 9 > Repeated Points: 1 > Iterations: 5000000 > Method: 0 start... > Method: 0 end... Average time one iteration: 8.474E-4ms > Method: 1 start... > Method: 1 end... Average time one iteration: 0.001378ms > Method: 2 start... > Method: 2 end... Average time one iteration: 4.396E-4ms > Base Points: 22 > Repeated Points: 3 > Iterations: 1000000 > Method: 0 start... > Method: 0 end... Average time one iteration: 0.002135ms > Method: 1 start... > Method: 1 end... Average time one iteration: 0.005063ms > Method: 2 start... > Method: 2 end... Average time one iteration: 0.002506ms > Base Points: 45 > Repeated Points: 5 > Iterations: 500000 > Method: 0 start... > Method: 0 end... Average time one iteration: 0.004596ms > Method: 1 start... > Method: 1 end... Average time one iteration: 0.012818ms > Method: 2 start... > Method: 2 end... Average time one iteration: 0.009758ms > Base Points: 90 > Repeated Points: 10 > Iterations: 50000 > Method: 0 start... > Method: 0 end... Average time one iteration: 0.00974ms > Method: 1 start... > Method: 1 end... Average time one iteration: 0.02988ms > Method: 2 start... > Method: 2 end... Average time one iteration: 0.03828ms > Base Points: 450 > Repeated Points: 50 > Iterations: 5000 > Method: 0 start... > Method: 0 end... Average time one iteration: 0.0582ms > Method: 1 start... > Method: 1 end... Average time one iteration: 0.22ms > Method: 2 start... > Method: 2 end... Average time one iteration: 0.942ms > Base Points: 900 > Repeated Points: 100 > Iterations: 500 > Method: 0 start... > Method: 0 end... Average time one iteration: 0.114ms > Method: 1 start... > Method: 1 end... Average time one iteration: 0.476ms > Method: 2 start... > Method: 2 end... Average time one iteration: 3.74ms > Base Points: 4500 > Repeated Points: 500 > Iterations: 20 > Method: 0 start... > Method: 0 end... Average time one iteration: 0.55ms > Method: 1 start... > Method: 1 end... Average time one iteration: 3.95ms > Method: 2 start... > Method: 2 end... Average time one iteration: 94.25ms > > > main function: > public static void repeatedPoints (Coordinate[] coors, int type) { > int n = 0; > > if (type == 0) { > HashSet hashCoor = new HashSet (); > > int prevSize = 0; > int newSize = 0; > > for (Coordinate c: coors) { > hashCoor.add(c); > newSize = hashCoor.size(); > if (newSize == prevSize) { > //This one is repeated > n++; > } > prevSize = newSize; > } > //it will work but i want to know witch points are repeated > //n = coors.length - hashCoor.size(); > } else if (type == 1) { > > n = 0; > KdTree kdtree = new KdTree(); > KdNode node; > for (Coordinate c: coors) { > node = kdtree.insert(c); > if (node.getCount() > 1) { > //This one is repeated > n++; > } > } > } else if (type == 2) { > //Brute force > n = 0; > int np = coors.length; > for (int i = 0; i < np - 1; i++) > for (int j = i+1; j < np; j++) { > if (coors[i].equals(coors[j])) { > n++; > } > } > } else Assert.shouldNeverReachHere(); > > //System.out.println ("\t\tTotal points: " + coors.length + " > Repeated points: " + n); > } > > > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > Jts-topo-suite-user mailing list > Jts-topo-suite-user@... > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user > > ```

 [Jts-topo-suite-user] how to find repeated points From: Jose C. Martinez-Llario - 2010-10-14 12:48 ```Hi, I want to find the repeated points in a geometry. I m not sure if JTS has already some exposed method with this functionallity. I was planning to do that in two different ways: - Brute force - Using STRtree I guess STRtree must be much better but dont know the limit (hundreds of vertexes, thousands of vertexes..?) to use it instead of using brute force. Another point is brute force is going to take little memory but I guess STRtree is going to take much more. Could someone give me some advise about that? Regards, Jose ```

 Re: [Jts-topo-suite-user] how to find repeated points From: Martin Davis - 2010-10-14 17:03 Attachments: Message as HTML ```I would just use a simple HashSet/Map with Coordinates as keys. This is likely to be as fast or faster as other more complex solutions. Or, JTS has a KD-tree index as well. STRtree is not such a good candidate, I think - too much overhead for building. Try both and report back on which one is faster! On Thu, Oct 14, 2010 at 5:48 AM, Jose C. Martinez-Llario < jomarlla@...> wrote: > Hi, > I want to find the repeated points in a geometry. I m not sure if JTS > has already some exposed method with this functionallity. > I was planning to do that in two different ways: > > - Brute force > - Using STRtree > > I guess STRtree must be much better but dont know the limit (hundreds of > vertexes, thousands of vertexes..?) to use it instead of using brute > force. Another point is brute force is going to take little memory but > I guess STRtree is going to take much more. > > Could someone give me some advise about that? > Regards, > Jose > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > 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] how to find repeated points From: Jose Carlos Martínez Llario - 2010-10-14 22:32 Attachments: Message as HTML ```Martin, Im doing some test with hashset and kdtree. With Kdtree if I dont use any tolerance then no point are considered repeated even though they are equal. Shouldnt this line in kdtree.java (method insert) be <= tolerance instead < tolerance, maybe? if (currentNode != null) { boolean isInTolerance = p.distance(currentNode.getCoordinate()) < tolerance; Thanx Jose On 14/10/2010 19:02, Martin Davis wrote: > I would just use a simple HashSet/Map with Coordinates as keys. This > is likely to be as fast or faster as other more complex solutions. > Or, JTS has a KD-tree index as well. > > STRtree is not such a good candidate, I think - too much overhead for > building. > > Try both and report back on which one is faster! > > On Thu, Oct 14, 2010 at 5:48 AM, Jose C. Martinez-Llario > > wrote: > > Hi, > I want to find the repeated points in a geometry. I m not sure if JTS > has already some exposed method with this functionallity. > I was planning to do that in two different ways: > > - Brute force > - Using STRtree > > I guess STRtree must be much better but dont know the limit > (hundreds of > vertexes, thousands of vertexes..?) to use it instead of using brute > force. Another point is brute force is going to take little > memory but > I guess STRtree is going to take much more. > > Could someone give me some advise about that? > Regards, > Jose > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating > great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > 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] how to find repeated points From: Martin Davis - 2010-10-15 05:00 ```Hmm, yes, that seems like a bug alright. I'll make the fix and try it out. Martin Jose Carlos Martínez Llario wrote: > Martin, Im doing some test with hashset and kdtree. > With Kdtree if I dont use any tolerance then no point are considered > repeated even though they are equal. > > Shouldnt this line in kdtree.java (method insert) be <= tolerance > instead < tolerance, maybe? > > if (currentNode != null) { > boolean isInTolerance = > p.distance(currentNode.getCoordinate()) < tolerance; > > Thanx > Jose > > > On 14/10/2010 19:02, Martin Davis wrote: >> I would just use a simple HashSet/Map with Coordinates as keys. This >> is likely to be as fast or faster as other more complex solutions. >> Or, JTS has a KD-tree index as well. >> >> STRtree is not such a good candidate, I think - too much overhead for >> building. >> >> Try both and report back on which one is faster! >> >> On Thu, Oct 14, 2010 at 5:48 AM, Jose C. Martinez-Llario >> > wrote: >> >> Hi, >> I want to find the repeated points in a geometry. I m not sure if JTS >> has already some exposed method with this functionallity. >> I was planning to do that in two different ways: >> >> - Brute force >> - Using STRtree >> >> I guess STRtree must be much better but dont know the limit >> (hundreds of >> vertexes, thousands of vertexes..?) to use it instead of using brute >> force. Another point is brute force is going to take little >> memory but >> I guess STRtree is going to take much more. >> >> Could someone give me some advise about that? >> Regards, >> Jose >> >> >> ------------------------------------------------------------------------------ >> Beautiful is writing same markup. Internet Explorer 9 supports >> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. >> Spend less time writing and rewriting code and more time >> creating great >> experiences on the web. Be a part of the beta today. >> http://p.sf.net/sfu/beautyoftheweb >> _______________________________________________ >> Jts-topo-suite-user mailing list >> Jts-topo-suite-user@... >> >> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user >> >> > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > ------------------------------------------------------------------------ > > _______________________________________________ > Jts-topo-suite-user mailing list > Jts-topo-suite-user@... > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user > ```

 [Jts-topo-suite-user] Unchecked Exceptions From: Jose C. Martinez-Llario - 2010-10-05 14:55 ```Hi, I would like to know which methods throw unchecked exceptions in JTS. For example, the method createPolygon in GeometryFactory throws an IllegalArgumentException but I had to look into the source code to find it out. TopologyException is another one. I would like to catch these exceptions to throw them again as checked expcetions. There is a faster way to know that?..I didnt find enough information in javadocs. I think JTS follows an unchecked exception model approach, this is going to be in the future too? Best, Jose ```

 Re: [Jts-topo-suite-user] Unchecked Exceptions From: Martin Davis - 2010-10-05 15:51 Attachments: Message as HTML ```Jose, You're right, JTS pretty much follows an unchecked exception model. Whether to use checked or unchecked exceptions is a constant debate in the Java world. I don't pretend to think I have the right answer - the use of unchecked exceptions is more due to historical accident than deliberate policy (although it does make the code easier to write!). In the case of TopologyException, this was introduced only after it became clear that topology failures could happen (ah, the naive optimism of the algorithm designer!). It was made unchecked to avoid breaking the API, and also because the hope is that at some point it really will disappear! For IllegalArgumentException, this was intended to follow the Java language practice. Although the language is itself conflicted on checked vs unchecked - viz NumberFormatException. Anyway, JTS does attempt to document the presence of unchecked exceptions in the Javadoc, but this is imperfectly done. I'll update the Javadoc for createPolygon. Further debate on checked vs unchecked is welcome, but be aware that I have little enthusiasm for breaking API changes. Martin On Tue, Oct 5, 2010 at 7:37 AM, Jose C. Martinez-Llario wrote: > Hi, > I would like to know which methods throw unchecked exceptions in JTS. > For example, > the method createPolygon in GeometryFactory throws an > IllegalArgumentException but I had to look into the source code to find > it out. > TopologyException is another one. > > I would like to catch these exceptions to throw them again as checked > expcetions. There is a faster way to know that?..I didnt find enough > information in javadocs. > > I think JTS follows an unchecked exception model approach, this is going > to be in the future too? > > Best, > Jose > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > 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] Unchecked Exceptions From: Jose C. Martinez-Llario - 2010-10-07 13:12 Attachments: Message as HTML ```Hi Martin, thanks for the detailed and good answer as usual. I was not asking for changing the jts model I respect your decision about using unchecked exception. Im still thinking about the exception model to use in jaspa because im going to rewrite it. I will check the papers you told me and your comments, maybe i can make up my mind :) It would be good to find more information about unchecked exceptions in jts documentation though. I think i know where jts throws unchecked exception but maybe i could be missing some methods. Anyways its not an important asking. Best, Jose El 05/10/2010 17:50, Martin Davis escribió: > Jose, > > You're right, JTS pretty much follows an unchecked exception model. > Whether to use checked or unchecked exceptions is a constant debate in > the Java world. I don't pretend to think I have the right answer - > the use of unchecked exceptions is more due to historical accident > than deliberate policy (although it does make the code easier to write!). > > In the case of TopologyException, this was introduced only after it > became clear that topology failures could happen (ah, the naive > optimism of the algorithm designer!). It was made unchecked to avoid > breaking the API, and also because the hope is that at some point it > really will disappear! > > For IllegalArgumentException, this was intended to follow the Java > language practice. Although the language is itself conflicted on > checked vs unchecked - viz NumberFormatException. > > Anyway, JTS does attempt to document the presence of unchecked > exceptions in the Javadoc, but this is imperfectly done. I'll update > the Javadoc for createPolygon. > > Further debate on checked vs unchecked is welcome, but be aware that I > have little enthusiasm for breaking API changes. > > Martin > > On Tue, Oct 5, 2010 at 7:37 AM, Jose C. Martinez-Llario > > wrote: > > Hi, > I would like to know which methods throw unchecked exceptions in JTS. > For example, > the method createPolygon in GeometryFactory throws an > IllegalArgumentException but I had to look into the source code to > find > it out. > TopologyException is another one. > > I would like to catch these exceptions to throw them again as checked > expcetions. There is a faster way to know that?..I didnt find enough > information in javadocs. > > I think JTS follows an unchecked exception model approach, this is > going > to be in the future too? > > Best, > Jose > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating > great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Jts-topo-suite-user mailing list > Jts-topo-suite-user@... > > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user > > ```

 [Jts-topo-suite-user] Unchecked excpetions From: Martin Davis - 2010-10-05 17:11 ```Further thoughts on this issue. This page: http://stackoverflow.com/questions/27578/when-to-choose-checked-and-unchecked-exceptions gives some good rules on how to choose checked or unchecked. I like this one: * *unchecked exception* within the code of my method for a *failure due to the caller* (that involves an *explicit and complete documentation *) * *checked exception* for a *failure due to the callee * that I need to make explicit to anyone wanting to use my code This pretty much summarizes the policy used in JTS. In both cases mentioned (createPolygon throwing IllegalArgumentException and overlay functions throwing TopologyException) the error is caused by the nature of the input, so the first rule above is used. In most cases, the caller is expected to provide valid input, in which case exceptions will not be thrown (e.g. properly structured rings, or valid geometry) Unfortunately in the case of overlay operations there are situations which can't be detected a priori and easily fixed by the caller. However, the intent of the library design is to eliminate such cases (i.e. handle all valid input correctly). So throwning a checked exception would embed a design limitation in the code. -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ```