You can subscribe to this list here.
2009 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}


2010 
_{Jan}
(30) 
_{Feb}
(41) 
_{Mar}
(69) 
_{Apr}
(131) 
_{May}
(67) 
_{Jun}
(24) 
_{Jul}
(28) 
_{Aug}
(52) 
_{Sep}
(9) 
_{Oct}
(24) 
_{Nov}
(36) 
_{Dec}
(24) 
2011 
_{Jan}
(20) 
_{Feb}
(53) 
_{Mar}
(31) 
_{Apr}
(74) 
_{May}
(71) 
_{Jun}
(51) 
_{Jul}
(28) 
_{Aug}
(91) 
_{Sep}
(72) 
_{Oct}
(46) 
_{Nov}
(90) 
_{Dec}
(38) 
2012 
_{Jan}
(80) 
_{Feb}
(77) 
_{Mar}
(98) 
_{Apr}
(78) 
_{May}
(56) 
_{Jun}
(85) 
_{Jul}
(53) 
_{Aug}
(87) 
_{Sep}
(74) 
_{Oct}
(67) 
_{Nov}
(85) 
_{Dec}
(66) 
2013 
_{Jan}
(50) 
_{Feb}
(34) 
_{Mar}
(45) 
_{Apr}
(36) 
_{May}
(22) 
_{Jun}
(10) 
_{Jul}
(30) 
_{Aug}
(39) 
_{Sep}
(25) 
_{Oct}
(11) 
_{Nov}
(64) 
_{Dec}
(42) 
2014 
_{Jan}
(27) 
_{Feb}
(6) 
_{Mar}
(10) 
_{Apr}
(14) 
_{May}
(25) 
_{Jun}
(6) 
_{Jul}
(25) 
_{Aug}
(3) 
_{Sep}
(22) 
_{Oct}
(12) 
_{Nov}
(34) 
_{Dec}
(15) 
2015 
_{Jan}
(24) 
_{Feb}
(20) 
_{Mar}
(11) 
_{Apr}

_{May}
(37) 
_{Jun}
(24) 
_{Jul}
(17) 
_{Aug}
(10) 
_{Sep}
(3) 
_{Oct}
(15) 
_{Nov}
(21) 
_{Dec}
(20) 
2016 
_{Jan}
(30) 
_{Feb}
(15) 
_{Mar}

_{Apr}

_{May}

_{Jun}
(1) 
_{Jul}
(20) 
_{Aug}

_{Sep}
(12) 
_{Oct}
(1) 
_{Nov}
(4) 
_{Dec}

S  M  T  W  T  F  S 







1

2
(1) 
3
(1) 
4
(1) 
5
(4) 
6

7
(1) 
8
(3) 
9
(2) 
10
(10) 
11
(4) 
12
(7) 
13
(2) 
14
(2) 
15

16

17
(1) 
18
(1) 
19
(5) 
20
(4) 
21
(3) 
22

23

24

25
(8) 
26
(3) 
27

28
(2) 
29

30
(2) 
31






From: Martin Davis <mtnclimb@te...>  20100530 15:21:10

Thanks, Thomas. You're right, that code really needed some lovin'! I essentially made your fixes, but with a few more improvements:  Added break statements in setOrdinate  Used CoordinateSequence.M enum value as the switch value Martin Thomas Fehr wrote: > Hi all > > here I think are some bugs and possible improvements. I kindly ask > somebody capable to test the proposed changes and feed them to the source . > > com.vividsolutions.jtsexample.geom.ExtendedCoordinateSequence: > > public void setOrdinate(int index, int ordinateIndex, double value) { > switch (ordinateIndex) { > case CoordinateSequence.X: > coordinates[index].x = value; > case CoordinateSequence.Y: > coordinates[index].y = value; > case CoordinateSequence.Z: > coordinates[index].z = value; > case 4: > coordinates[index].setM(value); > } > } > > > >  insert breaks >  replace case 4 by case CoordinateSequence.M (which value is 3!) > > public void setOrdinate(int index, int ordinateIndex, double value) { > switch (ordinateIndex) { > case CoordinateSequence.X: > coordinates[index].x = value; > break; > > case CoordinateSequence.Y: > coordinates[index].y = value; > break; > > case CoordinateSequence.Z: > coordinates[index].z = value; > break; > > case CoordinateSequence.M: > coordinates[index].setM(value); > break; > > } > > > and: > > public double getOrdinate(int index, int ordinateIndex) { > switch (ordinateIndex) { > case CoordinateSequence.X: > return coordinates[index].x; > case CoordinateSequence.Y: > return coordinates[index].y; > case CoordinateSequence.Z: > return coordinates[index].z; > case 4: > return coordinates[index].getM(); > } > return Double.NaN; > } > > > >  replace case 4 by case CoordinateSequence.M (which value is 3!) > > public double getOrdinate(int index, int ordinateIndex) { > switch (ordinateIndex) { > case CoordinateSequence.X: > return coordinates[index].x; > case CoordinateSequence.Y: > return coordinates[index].y; > case CoordinateSequence.Z: > return coordinates[index].z; > case CoordinateSequence.M: > return coordinates[index].getM(); > } > return Double.NaN; > } > > besides this there ar many unessesary casts and unused imports > > Thomas > > 
From: Thomas Fehr <thomas.fehr@fl...>  20100530 11:24:49

Hi all here I think are some bugs and possible improvements. I kindly ask somebody capable to test the proposed changes and feed them to the source . com.vividsolutions.jtsexample.geom.ExtendedCoordinateSequence: public void setOrdinate(int index, int ordinateIndex, double value) { switch (ordinateIndex) { case CoordinateSequence.X: coordinates[index].x = value; case CoordinateSequence.Y: coordinates[index].y = value; case CoordinateSequence.Z: coordinates[index].z = value; case 4: coordinates[index].setM(value); } } >  insert breaks  replace case 4 by case CoordinateSequence.M (which value is 3!) public void setOrdinate(int index, int ordinateIndex, double value) { switch (ordinateIndex) { case CoordinateSequence.X: coordinates[index].x = value; break; case CoordinateSequence.Y: coordinates[index].y = value; break; case CoordinateSequence.Z: coordinates[index].z = value; break; case CoordinateSequence.M: coordinates[index].setM(value); break; } and: public double getOrdinate(int index, int ordinateIndex) { switch (ordinateIndex) { case CoordinateSequence.X: return coordinates[index].x; case CoordinateSequence.Y: return coordinates[index].y; case CoordinateSequence.Z: return coordinates[index].z; case 4: return coordinates[index].getM(); } return Double.NaN; } >  replace case 4 by case CoordinateSequence.M (which value is 3!) public double getOrdinate(int index, int ordinateIndex) { switch (ordinateIndex) { case CoordinateSequence.X: return coordinates[index].x; case CoordinateSequence.Y: return coordinates[index].y; case CoordinateSequence.Z: return coordinates[index].z; case CoordinateSequence.M: return coordinates[index].getM(); } return Double.NaN; } besides this there ar many unessesary casts and unused imports Thomas  Flötenbau Thomas Fehr Seestrasse 185 CH8712 Stäfa Tel: +41 (0)44 926 65 26 Skype: thomas_fehr http://www.floetenbau.ch 
From: Martin Davis <mbdavis@re...>  20100528 15:28:19

Yes, it really only makes sense to use PreparedGeometry and a spatial index if you can cache the structures and make use of them many times. If you can't do this, then simply scanning a list of Geometrys will be faster. Martin Matthias Lendholt wrote: > Hi, > ok. I've tested my code with the PreparedGeometryIndex but it's not > significantly faster. I guess the index build or the creation of > PreparedGeometry objects take all the profits. Currently this is done > for each intersection run and I think this should be done static. > Since my algorithm is wrapped in a GeoTools Process that runs as > deegree Processlet in a WPS on Tomcat it is not so easy to debug it. > > Thanks again, > Matthias > > > Am 25.05.2010 18:07, schrieb Martin Davis: >> Great, Matthias, that's a good enhancement. >> >> I'm working on adding this functionality directly to JTS. There may be >> some changes in class name, but all the functionality will still work. >> >> Martin >> >> Matthias Lendholt wrote: >>> Hi, >>> >>> this is quite interesting for me too cause I was also working on >>> intersection tasks. But I'm working with GeoTools and handling >>> FeatureCollections which I have to iterate. Therefore I added >>> public void insert(Geometry geom) to PreparedGeometryIndex >>> which I can use by iterating over these FeatureCollection. Attached is >>> the modified version. >>> >>> Thanks a lot! >>> >>> Matthias >>> >>> >>> >>> Am 21.05.2010 19:12, schrieb Martin Davis: >>>> Jurgen, >>>> >>>> Attached is an example of preforming fast intersection testing by >>>> using >>>> a spatial index containing PreparedGeometries. >>>> >>>> This will be added to the JTS SVN. Comments or suggestions for >>>> improvements are welcome! >>>> Martin >>>> >>>> Martin Davis wrote: >>>>> Jurgen, you're right in thinking that there is a better way of >>>>> solving >>>>> your problem than the simple O(nm) nested loop approach. >>>>> >>>>> The best way to do this in JTS is: >>>>> >>>>>  Create PreparedGeometrys for the polygons >>>>>  Create a spatial index on the PreparedGeometries (STRtree is the >>>>> fastest choice) >>>>>  For each point p: >>>>>  query the index to find the set of PreparedGeometrys polySet >>>>> that p >>>>> potentially interacts with >>>>>  for each PreparedGeometry pg in polySet >>>>>  compute pg.intersects(p) >>>>> >>>>> This seems like a good thing to have as an example in JTS, or >>>>> possibly >>>>> even as a utility class. I'll work on creating something like this. >>>>> >>>>> Martin >>>>> >>>>> Jürgen Jacob wrote: >>>>>> Hi list, >>>>>> >>>>>> I have two sets of Geometry objects >>>>>> >>>>>>  a set of Points  a set of Multipolygons (federal states) >>>>>> >>>>>> and I have to check which of them intersect to get the mapping of >>>>>> Multipolygon>Points. >>>>>> geometryObjectA.intersect(geometryObjectB) returns true or false and >>>>>> the simplest but quite inefficient solution is: two nested loops >>>>>> iterating over both sets and check each pair if it intersects. Since >>>>>> a point could be intersected by more than polygon (if it lies on a >>>>>> edge or even a vertex) no breaks could be used in the loops. Very >>>>>> inefficient. >>>>>> >>>>>> I'm neither an expert in algorithm optimization nor in jts, >>>>>> therefore >>>>>> I'd like to know: >>>>>> >>>>>> Are there convenience functions that offer optimized algorithms for >>>>>> interection/union/.. tasks of geometry sets? >>>>>> >>>>>> If not: What should I do instead of iterating two times over these >>>>>> sets? The Multipolygons are quite complex (>1000 or even>10000 >>>>>> vertices and consisting of several polygons). I was thinking of >>>>>> first >>>>>> intersecting the Points with the envelope of the Multipolygons and >>>>>> only if this matches checking the Multipolygon itself. >>>>>> Other optimization ideas? >>>>>> >>>>>> Barking up the wrong tree? >>>>>> >>>>>> Thanks for any help! >>>>>> Jürgen >>>>> >>>> >>>> >>>> >>>>  >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Jtstoposuiteuser mailing list >>>> Jtstoposuiteuser@... >>>> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >>> >>> >> > >  Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 3833022 
From: Matthias Lendholt <matthias.lendholt@gf...>  20100528 07:21:21

Hi, ok. I've tested my code with the PreparedGeometryIndex but it's not significantly faster. I guess the index build or the creation of PreparedGeometry objects take all the profits. Currently this is done for each intersection run and I think this should be done static. Since my algorithm is wrapped in a GeoTools Process that runs as deegree Processlet in a WPS on Tomcat it is not so easy to debug it. Thanks again, Matthias Am 25.05.2010 18:07, schrieb Martin Davis: > Great, Matthias, that's a good enhancement. > > I'm working on adding this functionality directly to JTS. There may be > some changes in class name, but all the functionality will still work. > > Martin > > Matthias Lendholt wrote: >> Hi, >> >> this is quite interesting for me too cause I was also working on >> intersection tasks. But I'm working with GeoTools and handling >> FeatureCollections which I have to iterate. Therefore I added >> public void insert(Geometry geom) to PreparedGeometryIndex >> which I can use by iterating over these FeatureCollection. Attached is >> the modified version. >> >> Thanks a lot! >> >> Matthias >> >> >> >> Am 21.05.2010 19:12, schrieb Martin Davis: >>> Jurgen, >>> >>> Attached is an example of preforming fast intersection testing by using >>> a spatial index containing PreparedGeometries. >>> >>> This will be added to the JTS SVN. Comments or suggestions for >>> improvements are welcome! >>> Martin >>> >>> Martin Davis wrote: >>>> Jurgen, you're right in thinking that there is a better way of solving >>>> your problem than the simple O(nm) nested loop approach. >>>> >>>> The best way to do this in JTS is: >>>> >>>>  Create PreparedGeometrys for the polygons >>>>  Create a spatial index on the PreparedGeometries (STRtree is the >>>> fastest choice) >>>>  For each point p: >>>>  query the index to find the set of PreparedGeometrys polySet that p >>>> potentially interacts with >>>>  for each PreparedGeometry pg in polySet >>>>  compute pg.intersects(p) >>>> >>>> This seems like a good thing to have as an example in JTS, or possibly >>>> even as a utility class. I'll work on creating something like this. >>>> >>>> Martin >>>> >>>> Jürgen Jacob wrote: >>>>> Hi list, >>>>> >>>>> I have two sets of Geometry objects >>>>> >>>>>  a set of Points  a set of Multipolygons (federal states) >>>>> >>>>> and I have to check which of them intersect to get the mapping of >>>>> Multipolygon>Points. >>>>> geometryObjectA.intersect(geometryObjectB) returns true or false and >>>>> the simplest but quite inefficient solution is: two nested loops >>>>> iterating over both sets and check each pair if it intersects. Since >>>>> a point could be intersected by more than polygon (if it lies on a >>>>> edge or even a vertex) no breaks could be used in the loops. Very >>>>> inefficient. >>>>> >>>>> I'm neither an expert in algorithm optimization nor in jts, therefore >>>>> I'd like to know: >>>>> >>>>> Are there convenience functions that offer optimized algorithms for >>>>> interection/union/.. tasks of geometry sets? >>>>> >>>>> If not: What should I do instead of iterating two times over these >>>>> sets? The Multipolygons are quite complex (>1000 or even>10000 >>>>> vertices and consisting of several polygons). I was thinking of first >>>>> intersecting the Points with the envelope of the Multipolygons and >>>>> only if this matches checking the Multipolygon itself. >>>>> Other optimization ideas? >>>>> >>>>> Barking up the wrong tree? >>>>> >>>>> Thanks for any help! >>>>> Jürgen >>>> >>> >>> >>> >>>  >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Jtstoposuiteuser mailing list >>> Jtstoposuiteuser@... >>> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >> >> >  Matthias Lendholt [matthias.lendholt@...] tel: +49 331 288 1687; fax: +49 331 288 1703 GFZ German Research Centre for Geosciences Telegrafenberg A20; 14473 Potsdam; Germany 
From: G. Allegri <giohappy@gm...>  20100526 10:27:03

Hello. I'm doing various operations (buffer,etc.) on 2.5D polygons. The initial polygon rings contain coordinates with z value. After the operation the coordinates z value is set to NaN, so the returned geometry type is 2D. Questions: 1  is it possible to keep the original z value for the buffered geometry? I suppose it should be forced inside the BufferOp chain... 2  how to set the z values of all the buffered geometry coordinates to 0? It would be enough for me, because I simply need to return a pseudo3D geometry to Oracle (3003 gtype), but I don't care of the actual z value (for now...) Thanks, giovanni 
From: Martin Davis <mtnclimb@gm...>  20100526 03:10:00

Stefan, > > Btw: not sure, but wasn't there once (2006ish?) a difference with > respect to the set of delivered candidates for the Qtree or STRtree > (i.e. one missed some or delivered some cands that where far off)? > Cant find my email anymore and I was wondering when I should use which > index (besides the need for updates). > Yes, there is a subtlety to the behaviour of Quadtree. When it executes a query it will always return the set of items whose envelopes DO intersect the query geometry (just like the STRtree). However, it may also return other items as well. This is because it doesn't actually store the envelopes of the inserted items, so it can't test for envelope intersection at query time. It's the responsibility of the client to carry out a further envelope intersection test if required. In most cases the extra returned items are not many compared to the size of the tree, so this doesn't impose a large penalty. Maybe not the greatest choice of behaviour.... perhaps this should be changed in a future release. 
From: Stefan Steiniger <sstein@ge...>  20100526 02:46:37

I know, quite a bit late the answer and obvious too... but in OpenJUMP there are a couple of plugins that use a JTS spatial index to do queries. Most straight forward function I can think of is "Transfer Attributes" in Tools>Edit Attributes. Searching for the Qtree or STRtree class in the OJ code will help. Btw: not sure, but wasn't there once (2006ish?) a difference with respect to the set of delivered candidates for the Qtree or STRtree (i.e. one missed some or delivered some cands that where far off)? Cant find my email anymore and I was wondering when I should use which index (besides the need for updates). 
From: Markus Stocker <markus.stocker@gm...>  20100525 21:16:58

Martin, Thanks for the explanations. On Tue, May 25, 2010 at 10:45 PM, Martin Davis <mbdavis@...> wrote: > Not sure why the "k < 50" is making a difference. As Michael says, it's > possibly due to the effects of any or all of class loading, JIT > compilation, or envelope caching. Yes, this makes sense to me. > Something else that makes a performance difference in this kind of > situation is to use PreparedGeometrys. This is useful if you're going > to be querying the same polygonal geometry many times (where many is > large  in your case many = 50, which may or may not show some improvement). I'll test this. Cheers, markus > See this recent thread for some information about using > PreparedGeometrys and indexes: > > http://sourceforge.net/mailarchive/forum.php?thread_name=4BFBF5D4.6030507%40refractions.net&forum_name=jtstoposuiteuser > > Martin > > Markus Stocker wrote: >> Hi Michaël, >> >> Thanks for your reply. >> >> 2010/5/25 Michaël Michaud <michael.michaud@...>: >> >>> I don't know american states well enough to be sure, but I think that >>> (MD,NJ) envelopes intersect while (MD,IL) don't. >>> >> >> Yes, I think you are right, the envelopes intersect. >> >> >>> In the last case, the program is probably able to use a short circuit which >>> could explain such a difference. >>> >> >> Testing MD on all states returns longer timings for, >> >> DC(MD,MD) = false 1922460884 >> DC(MD,VA) = false 904726649 >> DC(MD,DE) = false 97096209 >> DC(MD,DC) = false 84331249 >> DC(MD,PA) = false 139669916 >> DC(MD,WV) = false 502460227 >> DC(MD,NJ) = true 15480809 >> >> Which are probably all explained by your hypothesis. >> >> >>> (NB : You can also eliminate most of notintersecting states by using an >>> index) >>> >> >> Is this documented somewhere? I have wondered whether or not there are >> special indexes one can build. >> >> Cheers, >> markus >> >> >>> Just to test : the increased difference when you add p1.disjoint(p2) may be >>> bacause the envelope is computed the first time it is used, then cached, so >>> that the time in the second disjoint() just includes envelope intersection. >>> >>> I'm sure Martin will correct me if some of my hypothesis are wrong. >>> >>> Michaël >>> >>> Markus Stocker a écrit : >>> >>>> Hi, >>>> >>>> I'm a new to JTS and stumbled upon something I don't have a clear >>>> explanation yet. I'm attaching an example test case that reproduces >>>> the problem. In essence, I'm loading the TIGER/Line 2009 US State >>>> shapefile [1] and I'm trying to find .disjoint() spatial relations >>>> between polygons. In doing so, I noticed that (deterministically) some >>>> pair tests take a significant longer time to test, e.g. >>>> >>>> DC(MD,IL) = true 3143 >>>> DC(MD,NJ) = true 13275849 >>>> >>>> meaning the test for spatial disjointness (DC) of (MD, IL) and (MD, >>>> NJ) are true and the former performs >4,000x faster. >>>> >>>> Does anyone have an explanation for this? >>>> >>>> I'm using JTS 1.11 and jumpcore 1.2. >>>> >>>> Thanks in advance. >>>> >>>> Best, >>>> markus >>>> >>>> ps: the k < 50 test in the code is not strictly necessary, but >>>> increases the difference in performance (Java loading or some >>>> inmemory indexing?). >>>> >>>> [1] http://www2.census.gov/cgibin/shapefiles2009/nationalfiles >>>> (State and Equivalent (Current)) >>>>  >>>> >>>> >>>>  >>>> >>>>  >>>> >>>> _______________________________________________ >>>> Jtstoposuiteuser mailing list >>>> Jtstoposuiteuser@... >>>> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >>>> >>> >> >>  >> >> _______________________________________________ >> Jtstoposuiteuser mailing list >> Jtstoposuiteuser@... >> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >> >> > >  > Martin Davis > Senior Technical Architect > Refractions Research, Inc. > (250) 3833022 > > >  > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > 
From: Martin Davis <mbdavis@re...>  20100525 20:44:51

Markus, Michael is correct  the difference in performance is due to the fact that in the MDIL case the envelopes don't intersect, so disjoint() can quickly shortcircuit to get the answer of False. In the case of MDNJ the full geometry intersection computation needs to be carried out, so the performance is much slower. Not sure why the "k < 50" is making a difference. As Michael says, it's possibly due to the effects of any or all of class loading, JIT compilation, or envelope caching. Something else that makes a performance difference in this kind of situation is to use PreparedGeometrys. This is useful if you're going to be querying the same polygonal geometry many times (where many is large  in your case many = 50, which may or may not show some improvement). See this recent thread for some information about using PreparedGeometrys and indexes: http://sourceforge.net/mailarchive/forum.php?thread_name=4BFBF5D4.6030507%40refractions.net&forum_name=jtstoposuiteuser Martin Markus Stocker wrote: > Hi Michaël, > > Thanks for your reply. > > 2010/5/25 Michaël Michaud <michael.michaud@...>: > >> I don't know american states well enough to be sure, but I think that >> (MD,NJ) envelopes intersect while (MD,IL) don't. >> > > Yes, I think you are right, the envelopes intersect. > > >> In the last case, the program is probably able to use a short circuit which >> could explain such a difference. >> > > Testing MD on all states returns longer timings for, > > DC(MD,MD) = false 1922460884 > DC(MD,VA) = false 904726649 > DC(MD,DE) = false 97096209 > DC(MD,DC) = false 84331249 > DC(MD,PA) = false 139669916 > DC(MD,WV) = false 502460227 > DC(MD,NJ) = true 15480809 > > Which are probably all explained by your hypothesis. > > >> (NB : You can also eliminate most of notintersecting states by using an >> index) >> > > Is this documented somewhere? I have wondered whether or not there are > special indexes one can build. > > Cheers, > markus > > >> Just to test : the increased difference when you add p1.disjoint(p2) may be >> bacause the envelope is computed the first time it is used, then cached, so >> that the time in the second disjoint() just includes envelope intersection. >> >> I'm sure Martin will correct me if some of my hypothesis are wrong. >> >> Michaël >> >> Markus Stocker a écrit : >> >>> Hi, >>> >>> I'm a new to JTS and stumbled upon something I don't have a clear >>> explanation yet. I'm attaching an example test case that reproduces >>> the problem. In essence, I'm loading the TIGER/Line 2009 US State >>> shapefile [1] and I'm trying to find .disjoint() spatial relations >>> between polygons. In doing so, I noticed that (deterministically) some >>> pair tests take a significant longer time to test, e.g. >>> >>> DC(MD,IL) = true 3143 >>> DC(MD,NJ) = true 13275849 >>> >>> meaning the test for spatial disjointness (DC) of (MD, IL) and (MD, >>> NJ) are true and the former performs >4,000x faster. >>> >>> Does anyone have an explanation for this? >>> >>> I'm using JTS 1.11 and jumpcore 1.2. >>> >>> Thanks in advance. >>> >>> Best, >>> markus >>> >>> ps: the k < 50 test in the code is not strictly necessary, but >>> increases the difference in performance (Java loading or some >>> inmemory indexing?). >>> >>> [1] http://www2.census.gov/cgibin/shapefiles2009/nationalfiles >>> (State and Equivalent (Current)) >>>  >>> >>> >>>  >>> >>>  >>> >>> _______________________________________________ >>> Jtstoposuiteuser mailing list >>> Jtstoposuiteuser@... >>> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >>> >> > >  > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > >  Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 3833022 
From: Markus Stocker <markus.stocker@gm...>  20100525 20:25:23

Hi Michaël, Thanks for your reply. 2010/5/25 Michaël Michaud <michael.michaud@...>: > I don't know american states well enough to be sure, but I think that > (MD,NJ) envelopes intersect while (MD,IL) don't. Yes, I think you are right, the envelopes intersect. > In the last case, the program is probably able to use a short circuit which > could explain such a difference. Testing MD on all states returns longer timings for, DC(MD,MD) = false 1922460884 DC(MD,VA) = false 904726649 DC(MD,DE) = false 97096209 DC(MD,DC) = false 84331249 DC(MD,PA) = false 139669916 DC(MD,WV) = false 502460227 DC(MD,NJ) = true 15480809 Which are probably all explained by your hypothesis. > (NB : You can also eliminate most of notintersecting states by using an > index) Is this documented somewhere? I have wondered whether or not there are special indexes one can build. Cheers, markus > Just to test : the increased difference when you add p1.disjoint(p2) may be > bacause the envelope is computed the first time it is used, then cached, so > that the time in the second disjoint() just includes envelope intersection. > > I'm sure Martin will correct me if some of my hypothesis are wrong. > > Michaël > > Markus Stocker a écrit : >> >> Hi, >> >> I'm a new to JTS and stumbled upon something I don't have a clear >> explanation yet. I'm attaching an example test case that reproduces >> the problem. In essence, I'm loading the TIGER/Line 2009 US State >> shapefile [1] and I'm trying to find .disjoint() spatial relations >> between polygons. In doing so, I noticed that (deterministically) some >> pair tests take a significant longer time to test, e.g. >> >> DC(MD,IL) = true 3143 >> DC(MD,NJ) = true 13275849 >> >> meaning the test for spatial disjointness (DC) of (MD, IL) and (MD, >> NJ) are true and the former performs >4,000x faster. >> >> Does anyone have an explanation for this? >> >> I'm using JTS 1.11 and jumpcore 1.2. >> >> Thanks in advance. >> >> Best, >> markus >> >> ps: the k < 50 test in the code is not strictly necessary, but >> increases the difference in performance (Java loading or some >> inmemory indexing?). >> >> [1] http://www2.census.gov/cgibin/shapefiles2009/nationalfiles >> (State and Equivalent (Current)) >>  >> >> >>  >> >>  >> >> _______________________________________________ >> Jtstoposuiteuser mailing list >> Jtstoposuiteuser@... >> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > 
From: Michaël Michaud <michael.michaud@fr...>  20100525 19:57:03

Hi, I don't know american states well enough to be sure, but I think that (MD,NJ) envelopes intersect while (MD,IL) don't. In the last case, the program is probably able to use a short circuit which could explain such a difference. (NB : You can also eliminate most of notintersecting states by using an index) Just to test : the increased difference when you add p1.disjoint(p2) may be bacause the envelope is computed the first time it is used, then cached, so that the time in the second disjoint() just includes envelope intersection. I'm sure Martin will correct me if some of my hypothesis are wrong. Michaël Markus Stocker a écrit : > Hi, > > I'm a new to JTS and stumbled upon something I don't have a clear > explanation yet. I'm attaching an example test case that reproduces > the problem. In essence, I'm loading the TIGER/Line 2009 US State > shapefile [1] and I'm trying to find .disjoint() spatial relations > between polygons. In doing so, I noticed that (deterministically) some > pair tests take a significant longer time to test, e.g. > > DC(MD,IL) = true 3143 > DC(MD,NJ) = true 13275849 > > meaning the test for spatial disjointness (DC) of (MD, IL) and (MD, > NJ) are true and the former performs >4,000x faster. > > Does anyone have an explanation for this? > > I'm using JTS 1.11 and jumpcore 1.2. > > Thanks in advance. > > Best, > markus > > ps: the k < 50 test in the code is not strictly necessary, but > increases the difference in performance (Java loading or some > inmemory indexing?). > > [1] http://www2.census.gov/cgibin/shapefiles2009/nationalfiles > (State and Equivalent (Current)) > >  > >  > >  > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser 
From: Markus Stocker <markus.stocker@gm...>  20100525 19:25:43

Hi, I'm a new to JTS and stumbled upon something I don't have a clear explanation yet. I'm attaching an example test case that reproduces the problem. In essence, I'm loading the TIGER/Line 2009 US State shapefile [1] and I'm trying to find .disjoint() spatial relations between polygons. In doing so, I noticed that (deterministically) some pair tests take a significant longer time to test, e.g. DC(MD,IL) = true 3143 DC(MD,NJ) = true 13275849 meaning the test for spatial disjointness (DC) of (MD, IL) and (MD, NJ) are true and the former performs >4,000x faster. Does anyone have an explanation for this? I'm using JTS 1.11 and jumpcore 1.2. Thanks in advance. Best, markus ps: the k < 50 test in the code is not strictly necessary, but increases the difference in performance (Java loading or some inmemory indexing?). [1] http://www2.census.gov/cgibin/shapefiles2009/nationalfiles (State and Equivalent (Current)) 
From: Martin Davis <mbdavis@re...>  20100525 16:06:47

Great, Matthias, that's a good enhancement. I'm working on adding this functionality directly to JTS. There may be some changes in class name, but all the functionality will still work. Martin Matthias Lendholt wrote: > Hi, > > this is quite interesting for me too cause I was also working on > intersection tasks. But I'm working with GeoTools and handling > FeatureCollections which I have to iterate. Therefore I added > public void insert(Geometry geom) to PreparedGeometryIndex > which I can use by iterating over these FeatureCollection. Attached is > the modified version. > > Thanks a lot! > > Matthias > > > > Am 21.05.2010 19:12, schrieb Martin Davis: >> Jurgen, >> >> Attached is an example of preforming fast intersection testing by using >> a spatial index containing PreparedGeometries. >> >> This will be added to the JTS SVN. Comments or suggestions for >> improvements are welcome! >> Martin >> >> Martin Davis wrote: >>> Jurgen, you're right in thinking that there is a better way of solving >>> your problem than the simple O(nm) nested loop approach. >>> >>> The best way to do this in JTS is: >>> >>>  Create PreparedGeometrys for the polygons >>>  Create a spatial index on the PreparedGeometries (STRtree is the >>> fastest choice) >>>  For each point p: >>>  query the index to find the set of PreparedGeometrys polySet that p >>> potentially interacts with >>>  for each PreparedGeometry pg in polySet >>>  compute pg.intersects(p) >>> >>> This seems like a good thing to have as an example in JTS, or possibly >>> even as a utility class. I'll work on creating something like this. >>> >>> Martin >>> >>> Jürgen Jacob wrote: >>>> Hi list, >>>> >>>> I have two sets of Geometry objects >>>> >>>>  a set of Points  a set of Multipolygons (federal states) >>>> >>>> and I have to check which of them intersect to get the mapping of >>>> Multipolygon>Points. >>>> geometryObjectA.intersect(geometryObjectB) returns true or false and >>>> the simplest but quite inefficient solution is: two nested loops >>>> iterating over both sets and check each pair if it intersects. Since >>>> a point could be intersected by more than polygon (if it lies on a >>>> edge or even a vertex) no breaks could be used in the loops. Very >>>> inefficient. >>>> >>>> I'm neither an expert in algorithm optimization nor in jts, therefore >>>> I'd like to know: >>>> >>>> Are there convenience functions that offer optimized algorithms for >>>> interection/union/.. tasks of geometry sets? >>>> >>>> If not: What should I do instead of iterating two times over these >>>> sets? The Multipolygons are quite complex (>1000 or even >10000 >>>> vertices and consisting of several polygons). I was thinking of first >>>> intersecting the Points with the envelope of the Multipolygons and >>>> only if this matches checking the Multipolygon itself. >>>> Other optimization ideas? >>>> >>>> Barking up the wrong tree? >>>> >>>> Thanks for any help! >>>> Jürgen >>> >> >> >> >>  >> >> >> >> >> >> _______________________________________________ >> Jtstoposuiteuser mailing list >> Jtstoposuiteuser@... >> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > >  Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 3833022 
From: Matthias Lendholt <matthias.lendholt@gf...>  20100525 13:41:03

Hi, this is quite interesting for me too cause I was also working on intersection tasks. But I'm working with GeoTools and handling FeatureCollections which I have to iterate. Therefore I added public void insert(Geometry geom) to PreparedGeometryIndex which I can use by iterating over these FeatureCollection. Attached is the modified version. Thanks a lot! Matthias Am 21.05.2010 19:12, schrieb Martin Davis: > Jurgen, > > Attached is an example of preforming fast intersection testing by using > a spatial index containing PreparedGeometries. > > This will be added to the JTS SVN. Comments or suggestions for > improvements are welcome! > Martin > > Martin Davis wrote: >> Jurgen, you're right in thinking that there is a better way of solving >> your problem than the simple O(nm) nested loop approach. >> >> The best way to do this in JTS is: >> >>  Create PreparedGeometrys for the polygons >>  Create a spatial index on the PreparedGeometries (STRtree is the >> fastest choice) >>  For each point p: >>  query the index to find the set of PreparedGeometrys polySet that p >> potentially interacts with >>  for each PreparedGeometry pg in polySet >>  compute pg.intersects(p) >> >> This seems like a good thing to have as an example in JTS, or possibly >> even as a utility class. I'll work on creating something like this. >> >> Martin >> >> Jürgen Jacob wrote: >>> Hi list, >>> >>> I have two sets of Geometry objects >>> >>>  a set of Points  a set of Multipolygons (federal states) >>> >>> and I have to check which of them intersect to get the mapping of >>> Multipolygon>Points. >>> geometryObjectA.intersect(geometryObjectB) returns true or false and >>> the simplest but quite inefficient solution is: two nested loops >>> iterating over both sets and check each pair if it intersects. Since >>> a point could be intersected by more than polygon (if it lies on a >>> edge or even a vertex) no breaks could be used in the loops. Very >>> inefficient. >>> >>> I'm neither an expert in algorithm optimization nor in jts, therefore >>> I'd like to know: >>> >>> Are there convenience functions that offer optimized algorithms for >>> interection/union/.. tasks of geometry sets? >>> >>> If not: What should I do instead of iterating two times over these >>> sets? The Multipolygons are quite complex (>1000 or even >10000 >>> vertices and consisting of several polygons). I was thinking of first >>> intersecting the Points with the envelope of the Multipolygons and >>> only if this matches checking the Multipolygon itself. >>> Other optimization ideas? >>> >>> Barking up the wrong tree? >>> >>> Thanks for any help! >>> Jürgen >> > > > >  > > > > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser  Matthias Lendholt [matthias.lendholt@...] tel: +49 331 288 1687; fax: +49 331 288 1703 GFZ German Research Centre for Geosciences Telegrafenberg A20; 14473 Potsdam; Germany 
From: Martin Tomko <martin.tomko@ge...>  20100525 08:51:09

Hi martin, I solved my problem... basically by contiguous set I meant a set of deg values such as : testArray1.add(1); testArray1.add(358); testArray1.add(360); testArray1.add(359); testArray1.add(2); testArray1.add(0); normally you would end up with 0,1,2,358,359,360 but I want: 358,359,360,0,1,2, and I have something like to solve it, which works: Comparator<Double> sortIncreasing = new Comparator<Double>(){ public int compare(Double i1, Double i2) { double a1 = Angle.normalize(Math.toRadians(i1)); double a2 = Angle.normalize(Math.toRadians(i2)); if ((i1>i2) && (a1>a2) ){ return 1; }else if ((i1>i2) && (a1<a2) ){ return 1; }else if ((i1<i2) && (a1>a2) ){ return 1; }else if ((i1<i2) && (a1<a2) ){ return 1; }else return 0; } }; Cheers for the tip about normalization, Martin 
From: Martin Davis <mbdavis@re...>  20100521 17:11:33

Jurgen, Attached is an example of preforming fast intersection testing by using a spatial index containing PreparedGeometries. This will be added to the JTS SVN. Comments or suggestions for improvements are welcome! Martin Martin Davis wrote: > Jurgen, you're right in thinking that there is a better way of solving > your problem than the simple O(nm) nested loop approach. > > The best way to do this in JTS is: > >  Create PreparedGeometrys for the polygons >  Create a spatial index on the PreparedGeometries (STRtree is the > fastest choice) >  For each point p: >  query the index to find the set of PreparedGeometrys polySet that p > potentially interacts with >  for each PreparedGeometry pg in polySet >  compute pg.intersects(p) > > This seems like a good thing to have as an example in JTS, or possibly > even as a utility class. I'll work on creating something like this. > > Martin > > Jürgen Jacob wrote: > >> Hi list, >> >> I have two sets of Geometry objects >> >>  a set of Points >>  a set of Multipolygons (federal states) >> >> and I have to check which of them intersect to get the mapping of Multipolygon>Points. >> geometryObjectA.intersect(geometryObjectB) returns true or false and the simplest but quite inefficient solution is: two nested loops iterating over both sets and check each pair if it intersects. Since a point could be intersected by more than polygon (if it lies on a edge or even a vertex) no breaks could be used in the loops. Very inefficient. >> >> I'm neither an expert in algorithm optimization nor in jts, therefore I'd like to know: >> >> Are there convenience functions that offer optimized algorithms for interection/union/.. tasks of geometry sets? >> >> If not: What should I do instead of iterating two times over these sets? The Multipolygons are quite complex (>1000 or even >10000 vertices and consisting of several polygons). I was thinking of first intersecting the Points with the envelope of the Multipolygons and only if this matches checking the Multipolygon itself. >> Other optimization ideas? >> >> Barking up the wrong tree? >> >> Thanks for any help! >> Jürgen >> >> > >  Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 3833022 
From: Martin Davis <mbdavis@re...>  20100521 15:49:48

Jurgen, you're right in thinking that there is a better way of solving your problem than the simple O(nm) nested loop approach. The best way to do this in JTS is:  Create PreparedGeometrys for the polygons  Create a spatial index on the PreparedGeometries (STRtree is the fastest choice)  For each point p:  query the index to find the set of PreparedGeometrys polySet that p potentially interacts with  for each PreparedGeometry pg in polySet  compute pg.intersects(p) This seems like a good thing to have as an example in JTS, or possibly even as a utility class. I'll work on creating something like this. Martin Jürgen Jacob wrote: > Hi list, > > I have two sets of Geometry objects > >  a set of Points >  a set of Multipolygons (federal states) > > and I have to check which of them intersect to get the mapping of Multipolygon>Points. > geometryObjectA.intersect(geometryObjectB) returns true or false and the simplest but quite inefficient solution is: two nested loops iterating over both sets and check each pair if it intersects. Since a point could be intersected by more than polygon (if it lies on a edge or even a vertex) no breaks could be used in the loops. Very inefficient. > > I'm neither an expert in algorithm optimization nor in jts, therefore I'd like to know: > > Are there convenience functions that offer optimized algorithms for interection/union/.. tasks of geometry sets? > > If not: What should I do instead of iterating two times over these sets? The Multipolygons are quite complex (>1000 or even >10000 vertices and consisting of several polygons). I was thinking of first intersecting the Points with the envelope of the Multipolygons and only if this matches checking the Multipolygon itself. > Other optimization ideas? > > Barking up the wrong tree? > > Thanks for any help! > Jürgen >  Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 3833022 
From: Jürgen Jacob <zoid.berg@gm...>  20100521 08:28:09

Hi list, I have two sets of Geometry objects  a set of Points  a set of Multipolygons (federal states) and I have to check which of them intersect to get the mapping of Multipolygon>Points. geometryObjectA.intersect(geometryObjectB) returns true or false and the simplest but quite inefficient solution is: two nested loops iterating over both sets and check each pair if it intersects. Since a point could be intersected by more than polygon (if it lies on a edge or even a vertex) no breaks could be used in the loops. Very inefficient. I'm neither an expert in algorithm optimization nor in jts, therefore I'd like to know: Are there convenience functions that offer optimized algorithms for interection/union/.. tasks of geometry sets? If not: What should I do instead of iterating two times over these sets? The Multipolygons are quite complex (>1000 or even >10000 vertices and consisting of several polygons). I was thinking of first intersecting the Points with the envelope of the Multipolygons and only if this matches checking the Multipolygon itself. Other optimization ideas? Barking up the wrong tree? Thanks for any help! Jürgen  GRATIS für alle GMXMitglieder: Die maxdome MovieFLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 
From: Martin Davis <mbdavis@re...>  20100520 21:36:12

As Sebastian says, the only tools that JTS really provides to help with this situation is to use snaprounding. Unfortunately, snaprounding is really more of a technique to improve robustness that it is one to clean up badlynoded data. There are often "spikes" and "gores" in spatial datasets which are large enough that if you tried to remove them by setting a very large snaprounding tolerance you would wind up with a dataset in which all vertices have been altered unacceptably. In other words, the spikes and gores are due to digitizing issues rather than limitations on the precision of the data. In the past I've written code that actually identifies spikes and gores directly (according to a set of tolerances) and "clips" them off to be merged with adjacent features. This code is not readily available, however. Sebastian Good wrote: > I had good luck with an approach suggested earlier, which is to use snap > rounding on the line segments before they are polygonized. > > var rawLinestrings = new java.util.ArrayList(preparedGs.Length); > foreach (var g in preparedGs) rawLinestrings.add(g.Jts.getBoundary()); > var nodedLinework = new > com.vividsolutions.jts.noding.snapround.GeometryNoder(new > PrecisionModel(10.0/tolerance)).node(rawLinestrings); > var nodedDedupedLinework = jtsFac.buildGeometry(nodedLinework).union(); > // now throw 'em into the polygonizer and run getPolygons > Polygonizer polygonizer = new Polygonizer(); > polygonizer.add(nodedDedupedLinework); > > > On Thu, May 20, 2010 at 3:30 PM, jaume dominguez faus <jaume@...>wrote: > > >> Hi list, >> >> I have a question regarding the Polygonizing. I've been writing complex >> topological processes based on the polygonizer results. But I often have >> to deal with situations in which the polygons created have very >> sharpened pieces because the coordinates of lines they were made of >> don't match exactly as I you can see in the pictures. >> >> this is a zoomtoextent view of the problem >> http://imagebin.org/97713 >> >> this is a 400% zoom to the area marked in side the red circle in the >> picture above >> http://imagebin.org/97714 >> >> this is a 2000% zoom which you can see what causes the problem >> http://imagebin.org/97717 >> >> >> >> So, the pursued result is to obtain is a polygonizing like in the first >> picture. But at the end, the leftmost polygon contains a very sharpened >> side in the top that confuses the subsequent process. My question is if >> it is possible to control this kind of things like by making some kind >> of snapping between lines, merging or polygonizing considering some sort >> of tolerance or any other suggestion you may have. >> >> Thanks in advance! >> >> Jaume. >> >> >>  >> >> _______________________________________________ >> Jtstoposuiteuser mailing list >> Jtstoposuiteuser@... >> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >> >> > > >  > >  > > >  > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >  Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 3833022 
From: Sebastian Good <sebastian@pa...>  20100520 20:54:16

I had good luck with an approach suggested earlier, which is to use snap rounding on the line segments before they are polygonized. var rawLinestrings = new java.util.ArrayList(preparedGs.Length); foreach (var g in preparedGs) rawLinestrings.add(g.Jts.getBoundary()); var nodedLinework = new com.vividsolutions.jts.noding.snapround.GeometryNoder(new PrecisionModel(10.0/tolerance)).node(rawLinestrings); var nodedDedupedLinework = jtsFac.buildGeometry(nodedLinework).union(); // now throw 'em into the polygonizer and run getPolygons Polygonizer polygonizer = new Polygonizer(); polygonizer.add(nodedDedupedLinework); On Thu, May 20, 2010 at 3:30 PM, jaume dominguez faus <jaume@...>wrote: > Hi list, > > I have a question regarding the Polygonizing. I've been writing complex > topological processes based on the polygonizer results. But I often have > to deal with situations in which the polygons created have very > sharpened pieces because the coordinates of lines they were made of > don't match exactly as I you can see in the pictures. > > this is a zoomtoextent view of the problem > http://imagebin.org/97713 > > this is a 400% zoom to the area marked in side the red circle in the > picture above > http://imagebin.org/97714 > > this is a 2000% zoom which you can see what causes the problem > http://imagebin.org/97717 > > > > So, the pursued result is to obtain is a polygonizing like in the first > picture. But at the end, the leftmost polygon contains a very sharpened > side in the top that confuses the subsequent process. My question is if > it is possible to control this kind of things like by making some kind > of snapping between lines, merging or polygonizing considering some sort > of tolerance or any other suggestion you may have. > > Thanks in advance! > > Jaume. > > >  > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > 
From: jaume dominguez faus <jaume@pl...>  20100520 20:50:58

Hi list, I have a question regarding the Polygonizing. I've been writing complex topological processes based on the polygonizer results. But I often have to deal with situations in which the polygons created have very sharpened pieces because the coordinates of lines they were made of don't match exactly as I you can see in the pictures. this is a zoomtoextent view of the problem http://imagebin.org/97713 this is a 400% zoom to the area marked in side the red circle in the picture above http://imagebin.org/97714 this is a 2000% zoom which you can see what causes the problem http://imagebin.org/97717 So, the pursued result is to obtain is a polygonizing like in the first picture. But at the end, the leftmost polygon contains a very sharpened side in the top that confuses the subsequent process. My question is if it is possible to control this kind of things like by making some kind of snapping between lines, merging or polygonizing considering some sort of tolerance or any other suggestion you may have. Thanks in advance! Jaume. 
From: andrea antonello <andrea.antonello@gm...>  20100520 17:01:18

Hi Stefan, thank you very much for the plugin info. I downloaded the code and will give it a look. As you say, probably only different density smoothing in my case will not work. What I am trying to implement and test now is a buffer protection area mechanism, and moving overlapping points to snap on the border of the buffer polygon of the line the current feature overlaps. Kind of messy, but I hope it will work :) Thanks, Andrea On Wed, May 19, 2010 at 7:22 PM, Stefan Steiniger <sstein@...> wrote: > Hei Andrea, > > well.. I worked once on a line smoothing algorithm that tries to avoid > overlaps by simple checking if they appear and then iteratively choosing > a different smoothing parameter that results in less smoothing. > > It is in (Open)JUMPs MapGen Toolbox: > https://sourceforge.net/projects/jumppilot/files/p_%20Map%20Generalization%20Plugin/Map%20Generalization%20Toolbox%20V1.0/mapgentoolbox_v1_0.zip/download > > > But I doubt that this will work in your case because the lines are just > too dense. > > but point densification before doing smoothing should help > > stefan > > > >  > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > 
From: Martin Davis <mtnclimb@te...>  20100519 23:14:46

I'm not understanding something... can't you just sort the values? It doesn't matter whether they're normalized to [Pi,Pi) or [0, 2Pi)  they'll obviously still sort correctly. But then no matter what the set of values is, it will be "contiguous" relative to that set. So I don't understand your specifying that they are contiguous... If you are still wondering how to solve the problem, perhaps post a problematic set of values and the desired solution? Martin Martin Tomko wrote: > Hi Martin D., > yes, it is a set of single values (azimuts), which means that the values > are normalizaed (0,2Pi) currently. Thanks for the hint, I will try > normalization (Pi,Pi)  I guess I will have to check the quadrants > occupied by the set to specify to the comparator whether to use the > normalization or not... > Alternatively, I think I could just check for the > or < relationship > with one and the other normalization and build a set of rules based on that. > Is that along the lines you had in mind? > Cheers > Martin T. > > > > > >>Do you mean you have a set of single angle values (eg 45, 80, 90 etc), > > >>> or a set of angular intervals (eg 4580, 8090, 90135, etc)? >>> > > >>> If the angles are single values, you can just normalize them to the >>> range [0, 2Pi] (or [Pi, Pi] and sort them directly. >>> > > >  > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > 
From: Stefan Steiniger <sstein@ge...>  20100519 17:23:15

Hei Andrea, well.. I worked once on a line smoothing algorithm that tries to avoid overlaps by simple checking if they appear and then iteratively choosing a different smoothing parameter that results in less smoothing. It is in (Open)JUMPs MapGen Toolbox: https://sourceforge.net/projects/jumppilot/files/p_%20Map%20Generalization%20Plugin/Map%20Generalization%20Toolbox%20V1.0/mapgentoolbox_v1_0.zip/download But I doubt that this will work in your case because the lines are just too dense. but point densification before doing smoothing should help stefan 
From: Michael Bedward <michael.bedward@gm...>  20100519 11:29:35

On 19 May 2010 18:30, andrea antonello wrote: > Anyways, I searched for the Denisfier class in the javadocs, but > wasn't able to find it. > It's a new class in JTS 1.11 Michael 