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

3

4

5

6
(5) 
7
(6) 
8
(7) 
9
(3) 
10
(1) 
11
(3) 
12
(1) 
13
(1) 
14

15

16

17

18

19

20

21

22

23

24

25

26
(8) 
27

28

29

30
(3) 
31
(1) 
From: Sebastian Good <sebastian@pa...>  20130831 15:39:02

When you convert from degrees to meters, choose your projection carefully. Different projections have different properties, e.g. doing better at preserving distance, angles, etc. Choose the wrong projection, e.g. Mercator, and you could have some wild discrepancies with reality. On Aug 30, 2013, at 3:44 PM, André Salvati <andre.f.salvati@...> wrote: > Srs, > > just a question. As I'm dealing with GPS data, I'm getting latitude and longitude in degrees, but as you know I can't build JTS shapes with "degrees". So, I'm looking for an API to convert this position in meters on the Earth's surface. > > I've tried GeoTools, but it doesn't goes well with my servers (Google App Engine). > > Would you recommend any other? > > Thanks > > > 2013/8/26 André Fernando Salvati <andre@...> > > Ok Martin, > > I'm going to do some tests and share the results. > > Thank you all for your comments and ideas. > > > 2013/8/26 Martin Davis <mtnclimb@...> > This is a very interesting question. Stefan and Michael have provided some useful comments. Here's a little more information about the issue, focussing on what's in JTS today, and what could be added to improve the story. > > As you point out, there are two general approaches to this computation: > > 1) buffer the LIneString by the query distance and compute "contains" (or actually "containsProperly", which is a simpler predicate) > 2) Compute the isWithinDistance predicate on the LineString > > It's hard to say which is faster *now* in JTS, and even harder to say which is theoretically the fastest. You'll really have to try both and see. Here's what's in JTS now: > > For #1, you should use PreparedGeometry to preprocess the buffer polygon. My guess is that the cost of computing the initial buffer is totally dominated by the query time. Then use the "cointainsProperly" predicate. This will utilized indexing to optimize the PointInPolygon computation. It is threadsafe now in trunk, so you may want to build from trunk and use that code. > > For #2, the current JTS isWithinDistance is not fully optimized for large LineStrings, since it uses a bruteforce approach. Still, if the input LineString has a fairly low number of vertices it may still be faster than #1. As Michael pointed out, this can be improve by indexing the LineString segments using an STRtree and using the nearestNeighbour method to do a fast NN query. The intention is to implement this in JTS as new methods on the PreparedGeometry class  most of the code is done, but it still needs to be packaged for production. > > It would be very interesting to hear which of these methods turns out to be the fasted in your case. > > > > On Mon, Aug 26, 2013 at 10:21 AM, André Salvati <andre.f.salvati@...> wrote: > Hi, > > I'm a beginner with JTS and this is my first post here. > > We've been working with geofences for a vehicle tracking app and I would like to know what solution could give me a lower CPU consumption. > > 1) Calculate and store a Buffered Area (100 meters) from a LineString object. Run 4 million times if my vehicle positions are inside or not that precalculated with contains() method. > > 2) Run 4 million times isWithinDistance() method from LineString for each position. > > Are there another options? > > Thanks. > >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > >  > Learn the latestVisual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of stepbystep > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk_______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser 
From: Stefan Steiniger <sstein@ge...>  20130830 20:54:33

not sure if this helps, but: (i) you can use points in degrees. However, your distance will be also in degree, which does not make much sense. But, for instance OpenTripPlanner uses OpenStreetMap data and just leaves the osm data in degrees. For the routing then (to get weights), it calculates distances as in (iii) below (ii) depends on your projection. Maybe you can also use proj4j and the Google Projection (EPSG:3857) http://trac.osgeo.org/proj4j/ http://wiki.openstreetmap.org/wiki/EPSG:3857 (iii) maybe you could actually use some of the scripts, if you interested only in converting distances: http://www.movabletype.co.uk/scripts/latlong.html cheers, stefan Am 30.08.13 16:44, schrieb André Salvati: > Srs, > > just a question. As I'm dealing with GPS data, I'm getting latitude and > longitude in degrees, but as you know I can't build JTS shapes with > "degrees". So, I'm looking for an API to convert this position in meters > on the Earth's surface. > > I've tried GeoTools, but it doesn't goes well with my servers (Google > App Engine). > > Would you recommend any other? > > Thanks > > > 2013/8/26 André Fernando Salvati <andre@... > <mailto:andre@...>> > > > Ok Martin, > > I'm going to do some tests and share the results. > > Thank you all for your comments and ideas. > > > 2013/8/26 Martin Davis <mtnclimb@... <mailto:mtnclimb@...>> > > This is a very interesting question. Stefan and Michael have > provided some useful comments. Here's a little more information > about the issue, focussing on what's in JTS today, and what > could be added to improve the story. > > As you point out, there are two general approaches to this > computation: > > 1) buffer the LIneString by the query distance and compute > "contains" (or actually "containsProperly", which is a simpler > predicate) > 2) Compute the isWithinDistance predicate on the LineString > > It's hard to say which is faster *now* in JTS, and even harder > to say which is theoretically the fastest. You'll really have > to try both and see. Here's what's in JTS now: > > For #1, you should use PreparedGeometry to preprocess the buffer > polygon. My guess is that the cost of computing the initial > buffer is totally dominated by the query time. Then use the > "cointainsProperly" predicate. This will utilized indexing to > optimize the PointInPolygon computation. It is threadsafe now > in trunk, so you may want to build from trunk and use that code. > > For #2, the current JTS isWithinDistance is not fully optimized > for large LineStrings, since it uses a bruteforce approach. > Still, if the input LineString has a fairly low number of > vertices it may still be faster than #1. As Michael pointed > out, this can be improve by indexing the LineString segments > using an STRtree and using the nearestNeighbour method to do a > fast NN query. The intention is to implement this in JTS as new > methods on the PreparedGeometry class  most of the code is > done, but it still needs to be packaged for production. > > It would be very interesting to hear which of these methods > turns out to be the fasted in your case. > > > > On Mon, Aug 26, 2013 at 10:21 AM, André Salvati > <andre.f.salvati@... <mailto:andre.f.salvati@...>> > wrote: > > Hi, > > I'm a beginner with JTS and this is my first post here. > > We've been working with geofences for a vehicle tracking app > and I would like to know what solution could give me a lower > CPU consumption. > > 1) Calculate and store a Buffered Area (100 meters) from a > LineString object. Run 4 million times if my vehicle > positions are inside or not that precalculated with > contains() method. > > 2) Run 4 million times isWithinDistance() method from > LineString for each position. > > Are there another options? > > Thanks. > >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, > insights, > analysis and resources for efficient Application Performance > Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > <mailto:Jtstoposuiteuser@...> > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance > Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > <mailto:Jtstoposuiteuser@...> > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > > > >  > Learn the latestVisual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of stepbystep > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > 
From: Martin Davis <mtnclimb@gm...>  20130830 20:50:32

Perhaps: http://trac.osgeo.org/proj4j/ (Disclaimer  I am one of the contributors) There's also CTS : https://github.com/irstv/CTS On Fri, Aug 30, 2013 at 1:44 PM, André Salvati <andre.f.salvati@...>wrote: > Srs, > > just a question. As I'm dealing with GPS data, I'm getting latitude and > longitude in degrees, but as you know I can't build JTS shapes with > "degrees". So, I'm looking for an API to convert this position in meters on > the Earth's surface. > > I've tried GeoTools, but it doesn't goes well with my servers (Google App > Engine). > > Would you recommend any other? > > > 
From: André Salvati <andre.f.salvati@gm...>  20130830 20:44:41

Srs, just a question. As I'm dealing with GPS data, I'm getting latitude and longitude in degrees, but as you know I can't build JTS shapes with "degrees". So, I'm looking for an API to convert this position in meters on the Earth's surface. I've tried GeoTools, but it doesn't goes well with my servers (Google App Engine). Would you recommend any other? Thanks 2013/8/26 André Fernando Salvati <andre@...> > > Ok Martin, > > I'm going to do some tests and share the results. > > Thank you all for your comments and ideas. > > > 2013/8/26 Martin Davis <mtnclimb@...> > >> This is a very interesting question. Stefan and Michael have provided >> some useful comments. Here's a little more information about the issue, >> focussing on what's in JTS today, and what could be added to improve the >> story. >> >> As you point out, there are two general approaches to this computation: >> >> 1) buffer the LIneString by the query distance and compute "contains" (or >> actually "containsProperly", which is a simpler predicate) >> 2) Compute the isWithinDistance predicate on the LineString >> >> It's hard to say which is faster *now* in JTS, and even harder to say >> which is theoretically the fastest. You'll really have to try both and >> see. Here's what's in JTS now: >> >> For #1, you should use PreparedGeometry to preprocess the buffer polygon. >> My guess is that the cost of computing the initial buffer is totally >> dominated by the query time. Then use the "cointainsProperly" predicate. >> This will utilized indexing to optimize the PointInPolygon computation. >> It is threadsafe now in trunk, so you may want to build from trunk and use >> that code. >> >> For #2, the current JTS isWithinDistance is not fully optimized for large >> LineStrings, since it uses a bruteforce approach. Still, if the input >> LineString has a fairly low number of vertices it may still be faster than >> #1. As Michael pointed out, this can be improve by indexing the LineString >> segments using an STRtree and using the nearestNeighbour method to do a >> fast NN query. The intention is to implement this in JTS as new methods on >> the PreparedGeometry class  most of the code is done, but it still needs >> to be packaged for production. >> >> It would be very interesting to hear which of these methods turns out to >> be the fasted in your case. >> >> >> >> On Mon, Aug 26, 2013 at 10:21 AM, André Salvati < >> andre.f.salvati@...> wrote: >> >>> Hi, >>> >>> I'm a beginner with JTS and this is my first post here. >>> >>> We've been working with geofences for a vehicle tracking app and I would >>> like to know what solution could give me a lower CPU consumption. >>> >>> 1) Calculate and store a Buffered Area (100 meters) from a LineString >>> object. Run 4 million times if my vehicle positions are inside or not that >>> precalculated with contains() method. >>> >>> 2) Run 4 million times isWithinDistance() method from LineString for >>> each position. >>> >>> Are there another options? >>> >>> Thanks. >>> >>> >>>  >>> Introducing Performance Central, a new site from SourceForge and >>> AppDynamics. Performance Central is your source for news, insights, >>> analysis and resources for efficient Application Performance Management. >>> Visit us today! >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Jtstoposuiteuser mailing list >>> Jtstoposuiteuser@... >>> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >>> >>> >> >> >>  >> Introducing Performance Central, a new site from SourceForge and >> AppDynamics. Performance Central is your source for news, insights, >> analysis and resources for efficient Application Performance Management. >> Visit us today! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jtstoposuiteuser mailing list >> Jtstoposuiteuser@... >> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >> >> > 
From: André Fernando Salvati <andre@no...>  20130826 20:49:13

Ok Martin, I'm going to do some tests and share the results. Thank you all for your comments and ideas. 2013/8/26 Martin Davis <mtnclimb@...> > This is a very interesting question. Stefan and Michael have provided > some useful comments. Here's a little more information about the issue, > focussing on what's in JTS today, and what could be added to improve the > story. > > As you point out, there are two general approaches to this computation: > > 1) buffer the LIneString by the query distance and compute "contains" (or > actually "containsProperly", which is a simpler predicate) > 2) Compute the isWithinDistance predicate on the LineString > > It's hard to say which is faster *now* in JTS, and even harder to say > which is theoretically the fastest. You'll really have to try both and > see. Here's what's in JTS now: > > For #1, you should use PreparedGeometry to preprocess the buffer polygon. > My guess is that the cost of computing the initial buffer is totally > dominated by the query time. Then use the "cointainsProperly" predicate. > This will utilized indexing to optimize the PointInPolygon computation. > It is threadsafe now in trunk, so you may want to build from trunk and use > that code. > > For #2, the current JTS isWithinDistance is not fully optimized for large > LineStrings, since it uses a bruteforce approach. Still, if the input > LineString has a fairly low number of vertices it may still be faster than > #1. As Michael pointed out, this can be improve by indexing the LineString > segments using an STRtree and using the nearestNeighbour method to do a > fast NN query. The intention is to implement this in JTS as new methods on > the PreparedGeometry class  most of the code is done, but it still needs > to be packaged for production. > > It would be very interesting to hear which of these methods turns out to > be the fasted in your case. > > > > On Mon, Aug 26, 2013 at 10:21 AM, André Salvati <andre.f.salvati@... > > wrote: > >> Hi, >> >> I'm a beginner with JTS and this is my first post here. >> >> We've been working with geofences for a vehicle tracking app and I would >> like to know what solution could give me a lower CPU consumption. >> >> 1) Calculate and store a Buffered Area (100 meters) from a LineString >> object. Run 4 million times if my vehicle positions are inside or not that >> precalculated with contains() method. >> >> 2) Run 4 million times isWithinDistance() method from LineString for >> each position. >> >> Are there another options? >> >> Thanks. >> >> >>  >> Introducing Performance Central, a new site from SourceForge and >> AppDynamics. Performance Central is your source for news, insights, >> analysis and resources for efficient Application Performance Management. >> Visit us today! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jtstoposuiteuser mailing list >> Jtstoposuiteuser@... >> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >> >> > > >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > 
From: Martin Davis <mtnclimb@gm...>  20130826 19:58:27

This is a very interesting question. Stefan and Michael have provided some useful comments. Here's a little more information about the issue, focussing on what's in JTS today, and what could be added to improve the story. As you point out, there are two general approaches to this computation: 1) buffer the LIneString by the query distance and compute "contains" (or actually "containsProperly", which is a simpler predicate) 2) Compute the isWithinDistance predicate on the LineString It's hard to say which is faster *now* in JTS, and even harder to say which is theoretically the fastest. You'll really have to try both and see. Here's what's in JTS now: For #1, you should use PreparedGeometry to preprocess the buffer polygon. My guess is that the cost of computing the initial buffer is totally dominated by the query time. Then use the "cointainsProperly" predicate. This will utilized indexing to optimize the PointInPolygon computation. It is threadsafe now in trunk, so you may want to build from trunk and use that code. For #2, the current JTS isWithinDistance is not fully optimized for large LineStrings, since it uses a bruteforce approach. Still, if the input LineString has a fairly low number of vertices it may still be faster than #1. As Michael pointed out, this can be improve by indexing the LineString segments using an STRtree and using the nearestNeighbour method to do a fast NN query. The intention is to implement this in JTS as new methods on the PreparedGeometry class  most of the code is done, but it still needs to be packaged for production. It would be very interesting to hear which of these methods turns out to be the fasted in your case. On Mon, Aug 26, 2013 at 10:21 AM, André Salvati <andre.f.salvati@...>wrote: > Hi, > > I'm a beginner with JTS and this is my first post here. > > We've been working with geofences for a vehicle tracking app and I would > like to know what solution could give me a lower CPU consumption. > > 1) Calculate and store a Buffered Area (100 meters) from a LineString > object. Run 4 million times if my vehicle positions are inside or not that > precalculated with contains() method. > > 2) Run 4 million times isWithinDistance() method from LineString for each > position. > > Are there another options? > > Thanks. > > >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > 
From: Stefan Steiniger <sstein@ge...>  20130826 19:19:50

Ah I see.. context is important ;) in that case, doing 1 should be faster  which is a point in polygon. It would be faster, because in case (2) you would still test from several points of the linestring to the point (Martin ?). But not sure if it is faster to "intersect" instead of using "contains".. (one op needs to also check boundary calculations). Maybe if you buffered your polygon already then you use: com.vividsolutions.jts.algorithm.MCPointInRing or checkout this class: com.vividsolutions.jts.algorithm.RayCrossingCounter lets see what others think, stefan Am 26.08.13 15:01, schrieb André Salvati: > Hi Stefan, > > the LineString is the route that the vehicle is supposed to follow > (public buses). > > The difference is that: > > 1) using 4 million times contains() from a Polygon object? > > Here I'm not going to run buffering 4 million times, because this > polygon was precalculated when I've changed the route (LineString), and > we have only a few changes in routes a day. So, buffering is irrelevant. > > 2) or using 4 million times isWithinDistance() from LineString object? > > Which one is faster? > > > 2013/8/26 Stefan Steiniger <sstein@... <mailto:sstein@...>> > > mhm.. > well, you could run a test... > > And avoiding 4 million tests does not seem to be possible. > > And not sure if this helps, you, but >  buffering is a fairly costly operation (and you should define also the > number of points for a quarter circle segment, e.g. the result for > buffering a point) >  if you have a fairly simple polygon describing the area limits (or is > it all linestrings? ... I also did not completely understand what you > LineString is), then a pointinpolygon test can be very fast > > but Martin D. my correct me here. > >  there is also the option to do some classification/trajectory > estimation based on previous data for one car (Kalmanfiltering) to see > if you need to do some testing (maybe you car did not move at all... so > the locationdifference has not changed). But I guess the processing of > 4 million units is simpler/faster? > >  finally splitting your data/fleet to contact only a certain server, as > form of parallel processing is an option too? > > stefan > > Am 26.08.13 13:56, schrieb André Salvati: > > Hi Stephan, > > > > thanks for your answer. > > > > This would be an useful solution for some batch processing that > we do. > > > > However, I meant that I'm receiving 4 million positions in > realtime from > > these vehicles (6000) every day, so the app must process > onebyone and > > generates alerts when some of them cross the boundaries. In this > case, > > you would go with 1), 2) or is there another option? > > > > > > > > > > 2013/8/26 Stefan Steiniger <sstein@... > <mailto:sstein@...> <mailto:sstein@... > <mailto:sstein@...>>> > > > > Hi Andre, > > > > if possible, you should use a spatial index, to do some > prefiltering. > > JTS comes with a Quadtree and RTree (STRtree) implemetation. > One is > > updatable while the other not (not sure though, which one). > > A spatial index allows you to retrieve only those objects from a > > dataset, that are fairly close/near by. > > > > Do you have objects that do not move around?, What are your 4 > Million > > objects? > > > > Also could you not buffer your objects only once and then > store them? > > > > best, > > stefan > > > > Am 26.08.13 13:21, schrieb André Salvati: > > > Hi, > > > > > > I'm a beginner with JTS and this is my first post here. > > > > > > We've been working with geofences for a vehicle tracking > app and > > I would > > > like to know what solution could give me a lower CPU > consumption. > > > > > > 1) Calculate and store a Buffered Area (100 meters) from a > LineString > > > object. Run 4 million times if my vehicle positions are > inside or not > > > that precalculated with contains() method. > > > > > > 2) Run 4 million times isWithinDistance() method from > LineString for > > > each position. > > > > > > Are there another options? > > > > > > Thanks. > > > > > > > > > > > >  > > > Introducing Performance Central, a new site from > SourceForge and > > > AppDynamics. Performance Central is your source for news, > insights, > > > analysis and resources for efficient Application Performance > > Management. > > > Visit us today! > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Jtstoposuiteuser mailing list > > > Jtstoposuiteuser@... > <mailto:Jtstoposuiteuser@...> > > <mailto:Jtstoposuiteuser@... > <mailto:Jtstoposuiteuser@...>> > > > > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > > > > > >  > > Introducing Performance Central, a new site from SourceForge and > > AppDynamics. Performance Central is your source for news, > insights, > > analysis and resources for efficient Application Performance > Management. > > Visit us today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > > _______________________________________________ > > Jtstoposuiteuser mailing list > > Jtstoposuiteuser@... > <mailto:Jtstoposuiteuser@...> > > <mailto:Jtstoposuiteuser@... > <mailto:Jtstoposuiteuser@...>> > > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > > > >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > <mailto:Jtstoposuiteuser@...> > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > 
From: Michaël Michaud <michael.michaud@fr...>  20130826 18:46:21

Hi, If your LineString has many points, I would split it into segments and index segments with a STRtree. In your scenario 1 and 2, the computer will have to compare each point with all line segments (or all buffer segments). Hard to say which one is faster without a try. If you index the linestring segments with a STRtree (the most efficient spatial index of JTS), you can compare points with segments which envelope are already within the distance. I think you can save time. Did not try though, it would also worth a try. Michaël Le 26/08/2013 20:29, Stefan Steiniger a écrit : > mhm.. > well, you could run a test... > > And avoiding 4 million tests does not seem to be possible. > > And not sure if this helps, you, but >  buffering is a fairly costly operation (and you should define also the > number of points for a quarter circle segment, e.g. the result for > buffering a point) >  if you have a fairly simple polygon describing the area limits (or is > it all linestrings? ... I also did not completely understand what you > LineString is), then a pointinpolygon test can be very fast > > but Martin D. my correct me here. > >  there is also the option to do some classification/trajectory > estimation based on previous data for one car (Kalmanfiltering) to see > if you need to do some testing (maybe you car did not move at all... so > the locationdifference has not changed). But I guess the processing of > 4 million units is simpler/faster? > >  finally splitting your data/fleet to contact only a certain server, as > form of parallel processing is an option too? > > stefan > > Am 26.08.13 13:56, schrieb André Salvati: >> Hi Stephan, >> >> thanks for your answer. >> >> This would be an useful solution for some batch processing that we do. >> >> However, I meant that I'm receiving 4 million positions in realtime from >> these vehicles (6000) every day, so the app must process onebyone and >> generates alerts when some of them cross the boundaries. In this case, >> you would go with 1), 2) or is there another option? >> >> >> >> >> 2013/8/26 Stefan Steiniger <sstein@... <mailto:sstein@...>> >> >> Hi Andre, >> >> if possible, you should use a spatial index, to do some prefiltering. >> JTS comes with a Quadtree and RTree (STRtree) implemetation. One is >> updatable while the other not (not sure though, which one). >> A spatial index allows you to retrieve only those objects from a >> dataset, that are fairly close/near by. >> >> Do you have objects that do not move around?, What are your 4 Million >> objects? >> >> Also could you not buffer your objects only once and then store them? >> >> best, >> stefan >> >> Am 26.08.13 13:21, schrieb André Salvati: >> > Hi, >> > >> > I'm a beginner with JTS and this is my first post here. >> > >> > We've been working with geofences for a vehicle tracking app and >> I would >> > like to know what solution could give me a lower CPU consumption. >> > >> > 1) Calculate and store a Buffered Area (100 meters) from a LineString >> > object. Run 4 million times if my vehicle positions are inside or not >> > that precalculated with contains() method. >> > >> > 2) Run 4 million times isWithinDistance() method from LineString for >> > each position. >> > >> > Are there another options? >> > >> > Thanks. >> > >> > >> > >>  >> > Introducing Performance Central, a new site from SourceForge and >> > AppDynamics. Performance Central is your source for news, insights, >> > analysis and resources for efficient Application Performance >> Management. >> > Visit us today! >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk >> > >> > >> > >> > _______________________________________________ >> > Jtstoposuiteuser mailing list >> > Jtstoposuiteuser@... >> <mailto:Jtstoposuiteuser@...> >> > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >> > >> >>  >> Introducing Performance Central, a new site from SourceForge and >> AppDynamics. Performance Central is your source for news, insights, >> analysis and resources for efficient Application Performance Management. >> Visit us today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jtstoposuiteuser mailing list >> Jtstoposuiteuser@... >> <mailto:Jtstoposuiteuser@...> >> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >> >> >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser 
From: Stefan Steiniger <sstein@ge...>  20130826 18:29:04

mhm.. well, you could run a test... And avoiding 4 million tests does not seem to be possible. And not sure if this helps, you, but  buffering is a fairly costly operation (and you should define also the number of points for a quarter circle segment, e.g. the result for buffering a point)  if you have a fairly simple polygon describing the area limits (or is it all linestrings? ... I also did not completely understand what you LineString is), then a pointinpolygon test can be very fast but Martin D. my correct me here.  there is also the option to do some classification/trajectory estimation based on previous data for one car (Kalmanfiltering) to see if you need to do some testing (maybe you car did not move at all... so the locationdifference has not changed). But I guess the processing of 4 million units is simpler/faster?  finally splitting your data/fleet to contact only a certain server, as form of parallel processing is an option too? stefan Am 26.08.13 13:56, schrieb André Salvati: > Hi Stephan, > > thanks for your answer. > > This would be an useful solution for some batch processing that we do. > > However, I meant that I'm receiving 4 million positions in realtime from > these vehicles (6000) every day, so the app must process onebyone and > generates alerts when some of them cross the boundaries. In this case, > you would go with 1), 2) or is there another option? > > > > > 2013/8/26 Stefan Steiniger <sstein@... <mailto:sstein@...>> > > Hi Andre, > > if possible, you should use a spatial index, to do some prefiltering. > JTS comes with a Quadtree and RTree (STRtree) implemetation. One is > updatable while the other not (not sure though, which one). > A spatial index allows you to retrieve only those objects from a > dataset, that are fairly close/near by. > > Do you have objects that do not move around?, What are your 4 Million > objects? > > Also could you not buffer your objects only once and then store them? > > best, > stefan > > Am 26.08.13 13:21, schrieb André Salvati: > > Hi, > > > > I'm a beginner with JTS and this is my first post here. > > > > We've been working with geofences for a vehicle tracking app and > I would > > like to know what solution could give me a lower CPU consumption. > > > > 1) Calculate and store a Buffered Area (100 meters) from a LineString > > object. Run 4 million times if my vehicle positions are inside or not > > that precalculated with contains() method. > > > > 2) Run 4 million times isWithinDistance() method from LineString for > > each position. > > > > Are there another options? > > > > Thanks. > > > > > > >  > > Introducing Performance Central, a new site from SourceForge and > > AppDynamics. Performance Central is your source for news, insights, > > analysis and resources for efficient Application Performance > Management. > > Visit us today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Jtstoposuiteuser mailing list > > Jtstoposuiteuser@... > <mailto:Jtstoposuiteuser@...> > > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > <mailto:Jtstoposuiteuser@...> > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > 
From: André Salvati <andre.f.salvati@gm...>  20130826 17:56:36

Hi Stephan, thanks for your answer. This would be an useful solution for some batch processing that we do. However, I meant that I'm receiving 4 million positions in realtime from these vehicles (6000) every day, so the app must process onebyone and generates alerts when some of them cross the boundaries. In this case, you would go with 1), 2) or is there another option? 2013/8/26 Stefan Steiniger <sstein@...> > Hi Andre, > > if possible, you should use a spatial index, to do some prefiltering. > JTS comes with a Quadtree and RTree (STRtree) implemetation. One is > updatable while the other not (not sure though, which one). > A spatial index allows you to retrieve only those objects from a > dataset, that are fairly close/near by. > > Do you have objects that do not move around?, What are your 4 Million > objects? > > Also could you not buffer your objects only once and then store them? > > best, > stefan > > Am 26.08.13 13:21, schrieb André Salvati: > > Hi, > > > > I'm a beginner with JTS and this is my first post here. > > > > We've been working with geofences for a vehicle tracking app and I would > > like to know what solution could give me a lower CPU consumption. > > > > 1) Calculate and store a Buffered Area (100 meters) from a LineString > > object. Run 4 million times if my vehicle positions are inside or not > > that precalculated with contains() method. > > > > 2) Run 4 million times isWithinDistance() method from LineString for > > each position. > > > > Are there another options? > > > > Thanks. > > > > > > >  > > Introducing Performance Central, a new site from SourceForge and > > AppDynamics. Performance Central is your source for news, insights, > > analysis and resources for efficient Application Performance Management. > > Visit us today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Jtstoposuiteuser mailing list > > Jtstoposuiteuser@... > > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > > >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > 
From: Stefan Steiniger <sstein@ge...>  20130826 17:30:42

Hi Andre, if possible, you should use a spatial index, to do some prefiltering. JTS comes with a Quadtree and RTree (STRtree) implemetation. One is updatable while the other not (not sure though, which one). A spatial index allows you to retrieve only those objects from a dataset, that are fairly close/near by. Do you have objects that do not move around?, What are your 4 Million objects? Also could you not buffer your objects only once and then store them? best, stefan Am 26.08.13 13:21, schrieb André Salvati: > Hi, > > I'm a beginner with JTS and this is my first post here. > > We've been working with geofences for a vehicle tracking app and I would > like to know what solution could give me a lower CPU consumption. > > 1) Calculate and store a Buffered Area (100 meters) from a LineString > object. Run 4 million times if my vehicle positions are inside or not > that precalculated with contains() method. > > 2) Run 4 million times isWithinDistance() method from LineString for > each position. > > Are there another options? > > Thanks. > > >  > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > 
From: André Salvati <andre.f.salvati@gm...>  20130826 17:21:36

Hi, I'm a beginner with JTS and this is my first post here. We've been working with geofences for a vehicle tracking app and I would like to know what solution could give me a lower CPU consumption. 1) Calculate and store a Buffered Area (100 meters) from a LineString object. Run 4 million times if my vehicle positions are inside or not that precalculated with contains() method. 2) Run 4 million times isWithinDistance() method from LineString for each position. Are there another options? Thanks. 
From: Richmond, Tanya <tanric@bg...>  20130813 15:14:14

Hi Martin I just thought I'd let you know that we have now found the solution to this problem. As you suspected, the fault does not lie within the JTS Topology functions, but within the interpretation of the unioned polygons by the modelling software that I am using. I am still slightly confused as to why the union command does not always place an identical ending coordinate to the starting coordinate, within the polygon, but this does not appear to cause a problem. Thank you for your help. Tanya Tanya Richmond Java Developer WSBLGN GMS Team Email: tanric@...<mailto:tanric@...> Tel: +44 (0)115 936 3193 British Geological Survey: Kingsley Dunham Centre, Keyworth, Nottingham. NG12 5GG. Website: http://www.bgs.ac.uk<http://www.bgs.ac.uk/>; Tel: +44 (0)115 936 3100 ________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. 
From: Martin Davis <mtnclimb@gm...>  20130812 14:57:32

Crossposting my reply on GitHub: To compute a full noding, use IntersectionAdder instead of IntersectionFinder. IntersectionFinderAdder only adds *proper*intersections. (This is stated in the Javadoc, but I agree that its implication is not obvious, and that the name of the class is not particularly descriptive. However, if you look at the JTS source code, you'll see that IntersectionAdder is used for general noding, while IntersectionFinderAdder is only used for snaprounding). To make all this clearer, I am going to copy IntersectionFinderAdder to a new class ProperIntersectionAdder, and deprecate IFA. On Sun, Aug 11, 2013 at 3:04 PM, Ryan Clark <ryan.clark@...> wrote: > I actually ran into this issue in working with JSTS ( > https://github.com/bjornharrtell/jsts), but it was suggested that I ask > about it here. > > Basically, it appears that if I start with two LineStrings that share a > common vertex, the noding algorithm (using MCIndexNoder) does not split the > lines into segments at the shared vertex. I saw similar behavior where a > line "touches" the other line but does not cross it. > > I described the issue here with pictures: > https://github.com/bjornharrtell/jsts/issues/137 > I wrote an example script (again, in JavaScript) here: > https://gist.github.com/rclark/6205437 > > I'm checking to see if this is expected behavior, if it has to do with > JSTS specifically, or if there's another way I should approach the problem? > The "touches" situation seems like it must be some kind of precision issue, > but I don't understand the situation where the two initial lines cross at a > shared vertex. > > If you want to try it out, here is a map<http://rclark.github.io/makepolys/>; that > lets you draw lines, select a set of them, and then run them through the > noding algorithm before running a polygonizer operation. You can easily > demonstrate the "touches" situation there  lines that "touch" but don't > cross will not define polygons, because the nodigin algorithm will not > produce the appropriate SegmentStrings. > > Thank you! > ____________________ > > Ryan Clark > Arizona Geological Survey > ryan.clark@... > (520) 3024871 > facebook.com/ModernGeologist <https://www.facebook.com/ModernGeologist>; > @worbly <https://twitter.com/worbly>; > > > > > > > > > > > >  > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to codelevel detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > 
From: Ryan Clark <ryan.clark@az...>  20130811 22:20:34

I actually ran into this issue in working with JSTS (https://github.com/bjornharrtell/jsts), but it was suggested that I ask about it here. Basically, it appears that if I start with two LineStrings that share a common vertex, the noding algorithm (using MCIndexNoder) does not split the lines into segments at the shared vertex. I saw similar behavior where a line "touches" the other line but does not cross it. I described the issue here with pictures: https://github.com/bjornharrtell/jsts/issues/137 I wrote an example script (again, in JavaScript) here: https://gist.github.com/rclark/6205437 I'm checking to see if this is expected behavior, if it has to do with JSTS specifically, or if there's another way I should approach the problem? The "touches" situation seems like it must be some kind of precision issue, but I don't understand the situation where the two initial lines cross at a shared vertex. If you want to try it out, here is a map<http://rclark.github.io/makepolys/>; that lets you draw lines, select a set of them, and then run them through the noding algorithm before running a polygonizer operation. You can easily demonstrate the "touches" situation there  lines that "touch" but don't cross will not define polygons, because the nodigin algorithm will not produce the appropriate SegmentStrings. Thank you! ____________________ Ryan Clark Arizona Geological Survey ryan.clark@...<mailto:ryan.clark@...> (520) 3024871 facebook.com/ModernGeologist<https://www.facebook.com/ModernGeologist>; @worbly<https://twitter.com/worbly>; 
From: Michaël Michaud <michael.michaud@fr...>  20130811 10:13:09

Le 11/08/2013 11:50, Jan Torben Heuer a écrit : > > Am 10.08.2013 um 18:49 schrieb JARRILUCEA@... > <mailto:JARRILUCEA@...> <jarrilucea@... > <mailto:jarrilucea@...>>: > >> Is there a way I can test whether a point is within a certain >> distance from a polygon considering the polygon as a line and not as >> area? One workaround would be to have a geometry with a hole but >> there may be a better approach. >> > > If you want to calculate the distance to the polygon's outer ring, you > can retrieve that with Polygon#getExteriorRing() Or maybe Polygon.getBoundary() to get also interior rings. It depends on your use case. Michaël > > HTH Jan > > >  > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to codelevel detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser 
From: Jan Torben Heuer <mail@jt...>  20130811 09:50:44

Am 10.08.2013 um 18:49 schrieb JARRILUCEA@... <jarrilucea@...>: > Is there a way I can test whether a point is within a certain distance from a polygon considering the polygon as a line and not as area? One workaround would be to have a geometry with a hole but there may be a better approach. > If you want to calculate the distance to the polygon's outer ring, you can retrieve that with Polygon#getExteriorRing() HTH Jan 
From: JARRILUCEA@YAHOO.COM <jarrilucea@ya...>  20130810 16:49:14

I have a polygontype geometry (MyGeometry) with no holes. When I use isWithinDistance to test if a given point inside MyGeometry is within a given distance, isWithinDistance always returns true: it does not matter which argument I pass as distance. Points inside MyGeometry are always within any passed distance. It appears that the polygon is considered as an area and any point inside it is 'within distance' Is there a way I can test whether a point is within a certain distance from a polygon considering the polygon as a line and not as area? One workaround would be to have a geometry with a hole but there may be a better approach. Thanks for this terrific tool and your support. Regards 
From: Martin Davis <mtnclimb@te...>  20130809 14:35:21

Tanya, The union executes fine in the JTS TestBuilder, using UnaryUnion (Geometry.union()). Geometry.union() is the recommended way to perform this operation. The WKT I used is below. I notice however that the output you supplied is missing a final closing coordinate, and when that is added it indeed looks incorrect like the image you showed. This makes me wonder if it's not JTS that's the problem, but something in the input/output module of your code. As I said, if you can supply the WKT for the geometries that go into the union, and the WKT for the output immediately after, that will confirm if it's a JTS problem, or elsewhere. Martin Input of 5 polygons: GEOMETRYCOLLECTION (POLYGON ((584068.9 269250.38, 584069.5 269262, 584073.4 269274.06, 584078.7 269284.72, 584086.5 269294.62, 584096 269302.84, 584108.1 269305.62, 584124.8 269305.28, 584142.56 269302.44, 584156.75 269298.2, 584169.06 269292.25, 584176.2 269286.84, 584186.1 269276.2, 584196.4 269262.34, 584209.5 269244.62, 584220.4 269232.1, 584229.75 269229.03, 584243.2 269225.47, 584254 269226.8, 584260.25 269234.7, 584266.6 269241.44, 584271.25 269252.78, 584270.2 269262.72, 584265.9 269267.7, 584261.06 269272.2, 584255.6 269283.62, 584245.3 269302.44, 584239.6 269322.3, 584237.2 269336.12, 584238.06 269345.3, 584237.9 269354.22, 584233.6 269369.47, 584224.75 269377.28, 584219.75 269384.72, 584218.4 269392.53, 584218.4 269404.22, 584232.75 269422.53, 584299.4 269394.25, 584393.1 269373.6, 584397.1 269369.12, 584401.06 269363.44, 584403.2 269349.97, 584400.3 269330.47, 584393.56 269312, 584384.7 269297.12, 584374.9 269280.44, 584372.4 269268.75, 584367.75 269248.53, 584362.44 269234, 584358.94 269219.12, 584355.7 269208.8, 584354.3 269194.97, 584352.2 269171.94, 584349 269154.2, 584345.94 269140.12, 584334.44 269130.06, 584315.6 269121.9, 584302.1 269117.66, 584291.1 269115.38, 584279.8 269114.12, 584260.3 269116.6, 584233.4 269122.28, 584200.7 269129.38, 584179.7 269135.4, 584151.44 269143.56, 584126.56 269154.2, 584103.06 269166.06, 584082.44 269195.56, 584068.9 269250.38)), POLYGON ((584374.2 269114.8, 584368.6 269105.75, 584365.8 269098.3, 584364.6 269087.38, 584363.7 269076.94, 584367.44 269065.06, 584377.9 269052.06, 584390.2 269039.5, 584404.4 269031.6, 584417.6 269028.34, 584429.75 269027.4, 584440.75 269028, 584450.7 269032.28, 584457.9 269036.72, 584463 269042.97, 584466.5 269060.4, 584463.94 269070.88, 584460.44 269083.9, 584458.56 269089.94, 584456.7 269098.3, 584452.75 269106.7, 584448.3 269113.88, 584443.7 269118.3, 584438.3 269121.56, 584427.2 269123.88, 584413.7 269125.75, 584401.4 269125.97, 584389.6 269124.56, 584379.06 269119.47, 584374.2 269114.8)), POLYGON ((584830.7 269050.66, 584821.4 269051.53, 584812.9 269054.72, 584805.7 269058.75, 584799.2 269063.72, 584794.1 269070.16, 584790.6 269078.78, 584787.06 269091.38, 584786.8 269106.1, 584787.5 269125.5, 584790.94 269142.47, 584796.75 269154.34, 584802.4 269161.94, 584804.7 269171.22, 584803.6 269178.84, 584802.1 269184.47, 584799.1 269187.94, 584794.7 269190.78, 584790 269191.66, 584785.06 269191.66, 584780.3 269190.78, 584775.44 269189.3, 584767.94 269187.84, 584760.06 269187.84, 584751.75 269188.53, 584745.94 269190.1, 584739.2 269193, 584735.9 269195.66, 584732.2 269198.62, 584728.2 269202, 584723.6 269201.6, 584716.7 269197.75, 584711.5 269193.25, 584709.25 269188.75, 584703 269183.34, 584693.3 269178.62, 584684.06 269176.8, 584675.75 269177.28, 584668.1 269177.72, 584658.7 269183.62, 584652.5 269190.16, 584645.6 269199.66, 584640.4 269204.25, 584633.2 269205.56, 584626.3 269202.94, 584622.2 269192.03, 584619.94 269181.56, 584619.94 269171.12, 584621.75 269152.94, 584621.75 269135.66, 584620.4 269121.1, 584617.7 269106.53, 584614.94 269098.8, 584609.5 269098.34, 584598.1 269100.2, 584587.6 269105.2, 584579 269112.9, 584575.4 269120.2, 584573.1 269131.56, 584572.6 269143.84, 584572.6 269156.1, 584574.44 269169.28, 584574.94 269183.38, 584574 269198.4, 584569.94 269214.3, 584565.8 269229.78, 584559 269252.5, 584557.2 269264.34, 584555.4 269278.88, 584558.1 269304.8, 584563.1 269323, 584571.3 269333.44, 584611.3 269325.25, 584620.75 269317.97, 584627.9 269310.53, 584632.94 269302.8, 584637.7 269297.44, 584642.2 269293.28, 584646.6 269291.2, 584653.2 269289.72, 584660.94 269289.12, 584671.3 269288.8, 584679.06 269289.4, 584685.9 269290.72, 584693.5 269292.4, 584698.75 269295.97, 584715.7 269292.38, 584718.25 269284.97, 584725.94 269280.25, 584732.2 269280.47, 584738.06 269283.84, 584751.4 269287.06, 584773.4 269277.47, 584780.4 269275.16, 584791.6 269275.56, 584799.06 269275.56, 584806.06 269276.62, 584811.56 269276.62, 584823.44 269273.66, 584833.8 269272.12, 584964.6 269254.8, 584973.3 269252.47, 584982.25 269251.22, 584991.75 269248.66, 584987.3 269234.03, 584981.56 269218.12, 584973.6 269208.56, 584968.56 269202.84, 584963.44 269198.06, 584956.44 269194.25, 584949.75 269191.7, 584939.9 269189.16, 584928.44 269188.84, 584915 269192.56, 584903.3 269197.5, 584894.5 269201.34, 584887.75 269205.16, 584882.4 269206.28, 584876.4 269206.6, 584871.56 269206.72, 584866.9 269205.38, 584864.1 269202.5, 584862.8 269197.28, 584863.06 269189.62, 584864.4 269180.88, 584865.94 269173.38, 584868.44 269162.88, 584872 269151.38, 584874.06 269139.9, 584875.9 269128.9, 584875.06 269115.2, 584872.94 269103.28, 584869.3 269089.78, 584864.4 269077.62, 584859.56 269066.53, 584855.4 269060.78, 584850 269056.06, 584839.44 269051.78, 584830.7 269050.66)), POLYGON ((584318.4 269092.28, 584314.94 269098.5, 584314.7 269109, 584316.4 269118.34, 584322.6 269129.4, 584330.25 269136.47, 584337.06 269142.72, 584338.75 269149.5, 584342.1 269166.78, 584348.4 269178.12, 584364.8 269190.56, 584378.4 269195.7, 584388.3 269200.5, 584402.5 269210.97, 584412.7 269214.94, 584420.9 269216.9, 584430.8 269216.9, 584437.6 269216.06, 584449.5 269214.66, 584460.8 269214.94, 584471.9 269212.38, 584481.5 269208.12, 584494.56 269203.3, 584508.1 269195.12, 584517.5 269183.78, 584526.25 269169.62, 584534.2 269151.22, 584537.9 269143, 584541.9 269137.03, 584544.94 269129.7, 584545.5 269120.62, 584544.1 269114.66, 584541.9 269111.53, 584533.4 269107.6, 584521.2 269105.6, 584508.7 269104.75, 584497.6 269105.03, 584488.9 269104.2, 584480.7 269103.62, 584471 269103.34, 584458.56 269104.75, 584449.5 269107, 584439.3 269109, 584429.4 269109.28, 584419.5 269110.97, 584406.44 269110.7, 584396.8 269108.44, 584386.9 269104.47, 584377.56 269099.94, 584366.8 269095.4, 584357.1 269090.6, 584345.25 269088.03, 584333.4 269087.47, 584324 269089.44, 584318.4 269092.28)), POLYGON ((584634.1 269182.97, 584643.3 269186.34, 584659.56 269186.84, 584670.75 269183.94, 584674.6 269180.34, 584677.8 269175.78, 584679.9 269167.6, 584680.75 269158.47, 584681.44 269144.56, 584681.44 269133.84, 584681.6 269123.22, 584681.2 269113.56, 584679.2 269100.6, 584675.06 269088.7, 584672.1 269084.4, 584665.6 269081.78, 584661.2 269081, 584656.1 269081.66, 584645.2 269084.2, 584635.2 269088.06, 584628.8 269091.94, 584623.7 269095.44, 584618.3 269105.6, 584615.1 269120.62, 584614.44 269135.7, 584615.4 269147.53, 584617.2 269156.66, 584621.06 269166.9, 584627.7 269177.38, 584634.1 269182.97))) On 8/9/2013 12:58 AM, Richmond, Tanya wrote: > Hi Martin > I'm sorry, but I cannot work out how to reply directly on the forum  > do I need a logon? > Anyway, I have attached a text file which has the information about > the polygon coordinates. I hope this helps. I am in the UK and these > coordinates are UK map references (Northings/Eastings). > Please let me know if you need any further information. > Best Wishes > Tanya > 
From: Martin Davis <mtnclimb@te...>  20130809 14:23:18

You need to sign up to the list to be able to post. You can do that here: https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser Can you supply the data as WKT? This makes it *much* easier to test using the TestBuilder. On 8/9/2013 12:58 AM, Richmond, Tanya wrote: > Hi Martin > I'm sorry, but I cannot work out how to reply directly on the forum  > do I need a logon? > Anyway, I have attached a text file which has the information about > the polygon coordinates. I hope this helps. I am in the UK and these > coordinates are UK map references (Northings/Eastings). > Please let me know if you need any further information. > Best Wishes > Tanya > 
From: Richmond, Tanya <tanric@bg...>  20130809 07:58:56

Original ununioned polygons Polygon1 x:584068.9 y:269250.38 x:584069.5 y:269262.0 x:584073.4 y:269274.06 x:584078.7 y:269284.72 x:584086.5 y:269294.62 x:584096.0 y:269302.84 x:584108.1 y:269305.62 x:584124.8 y:269305.28 x:584142.56 y:269302.44 x:584156.75 y:269298.2 x:584169.06 y:269292.25 x:584176.2 y:269286.84 x:584186.1 y:269276.2 x:584196.4 y:269262.34 x:584209.5 y:269244.62 x:584220.4 y:269232.1 x:584229.75 y:269229.03 x:584243.2 y:269225.47 x:584254.0 y:269226.8 x:584260.25 y:269234.7 x:584266.6 y:269241.44 x:584271.25 y:269252.78 x:584270.2 y:269262.72 x:584265.9 y:269267.7 x:584261.06 y:269272.2 x:584255.6 y:269283.62 x:584245.3 y:269302.44 x:584239.6 y:269322.3 x:584237.2 y:269336.12 x:584238.06 y:269345.3 x:584237.9 y:269354.22 x:584233.6 y:269369.47 x:584224.75 y:269377.28 x:584219.75 y:269384.72 x:584218.4 y:269392.53 x:584218.4 y:269404.22 x:584232.75 y:269422.53 x:584299.4 y:269394.25 x:584393.1 y:269373.6 x:584397.1 y:269369.12 x:584401.06 y:269363.44 x:584403.2 y:269349.97 x:584400.3 y:269330.47 x:584393.56 y:269312.0 x:584384.7 y:269297.12 x:584374.9 y:269280.44 x:584372.4 y:269268.75 x:584367.75 y:269248.53 x:584362.44 y:269234.0 x:584358.94 y:269219.12 x:584355.7 y:269208.8 x:584354.3 y:269194.97 x:584352.2 y:269171.94 x:584349.0 y:269154.2 x:584345.94 y:269140.12 x:584334.44 y:269130.06 x:584315.6 y:269121.9 x:584302.1 y:269117.66 x:584291.1 y:269115.38 x:584279.8 y:269114.12 x:584260.3 y:269116.6 x:584233.4 y:269122.28 x:584200.7 y:269129.38 x:584179.7 y:269135.4 x:584151.44 y:269143.56 x:584126.56 y:269154.2 x:584103.06 y:269166.06 x:584082.44 y:269195.56 x:584068.9 y:269250.38 Polygon2 x:584374.2 y:269114.8 x:584368.6 y:269105.75 x:584365.8 y:269098.3 x:584364.6 y:269087.38 x:584363.7 y:269076.94 x:584367.44 y:269065.06 x:584377.9 y:269052.06 x:584390.2 y:269039.5 x:584404.4 y:269031.6 x:584417.6 y:269028.34 x:584429.75 y:269027.4 x:584440.75 y:269028.0 x:584450.7 y:269032.28 x:584457.9 y:269036.72 x:584463.0 y:269042.97 x:584466.5 y:269060.4 x:584463.94 y:269070.88 x:584460.44 y:269083.9 x:584458.56 y:269089.94 x:584456.7 y:269098.3 x:584452.75 y:269106.7 x:584448.3 y:269113.88 x:584443.7 y:269118.3 x:584438.3 y:269121.56 x:584427.2 y:269123.88 x:584413.7 y:269125.75 x:584401.4 y:269125.97 x:584389.6 y:269124.56 x:584379.06 y:269119.47 x:584374.2 y:269114.8 Polygon3 x:584830.7 y:269050.66 x:584821.4 y:269051.53 x:584812.9 y:269054.72 x:584805.7 y:269058.75 x:584799.2 y:269063.72 x:584794.1 y:269070.16 x:584790.6 y:269078.78 x:584787.06 y:269091.38 x:584786.8 y:269106.1 x:584787.5 y:269125.5 x:584790.94 y:269142.47 x:584796.75 y:269154.34 x:584802.4 y:269161.94 x:584804.7 y:269171.22 x:584803.6 y:269178.84 x:584802.1 y:269184.47 x:584799.1 y:269187.94 x:584794.7 y:269190.78 x:584790.0 y:269191.66 x:584785.06 y:269191.66 x:584780.3 y:269190.78 x:584775.44 y:269189.3 x:584767.94 y:269187.84 x:584760.06 y:269187.84 x:584751.75 y:269188.53 x:584745.94 y:269190.1 x:584739.2 y:269193.0 x:584735.9 y:269195.66 x:584732.2 y:269198.62 x:584728.2 y:269202.0 x:584723.6 y:269201.6 x:584716.7 y:269197.75 x:584711.5 y:269193.25 x:584709.25 y:269188.75 x:584703.0 y:269183.34 x:584693.3 y:269178.62 x:584684.06 y:269176.8 x:584675.75 y:269177.28 x:584668.1 y:269177.72 x:584658.7 y:269183.62 x:584652.5 y:269190.16 x:584645.6 y:269199.66 x:584640.4 y:269204.25 x:584633.2 y:269205.56 x:584626.3 y:269202.94 x:584622.2 y:269192.03 x:584619.94 y:269181.56 x:584619.94 y:269171.12 x:584621.75 y:269152.94 x:584621.75 y:269135.66 x:584620.4 y:269121.1 x:584617.7 y:269106.53 x:584614.94 y:269098.8 x:584609.5 y:269098.34 x:584598.1 y:269100.2 x:584587.6 y:269105.2 x:584579.0 y:269112.9 x:584575.4 y:269120.2 x:584573.1 y:269131.56 x:584572.6 y:269143.84 x:584572.6 y:269156.1 x:584574.44 y:269169.28 x:584574.94 y:269183.38 x:584574.0 y:269198.4 x:584569.94 y:269214.3 x:584565.8 y:269229.78 x:584559.0 y:269252.5 x:584557.2 y:269264.34 x:584555.4 y:269278.88 x:584558.1 y:269304.8 x:584563.1 y:269323.0 x:584571.3 y:269333.44 x:584611.3 y:269325.25 x:584620.75 y:269317.97 x:584627.9 y:269310.53 x:584632.94 y:269302.8 x:584637.7 y:269297.44 x:584642.2 y:269293.28 x:584646.6 y:269291.2 x:584653.2 y:269289.72 x:584660.94 y:269289.12 x:584671.3 y:269288.8 x:584679.06 y:269289.4 x:584685.9 y:269290.72 x:584693.5 y:269292.4 x:584698.75 y:269295.97 x:584715.7 y:269292.38 x:584718.25 y:269284.97 x:584725.94 y:269280.25 x:584732.2 y:269280.47 x:584738.06 y:269283.84 x:584751.4 y:269287.06 x:584773.4 y:269277.47 x:584780.4 y:269275.16 x:584791.6 y:269275.56 x:584799.06 y:269275.56 x:584806.06 y:269276.62 x:584811.56 y:269276.62 x:584823.44 y:269273.66 x:584833.8 y:269272.12 x:584964.6 y:269254.8 x:584973.3 y:269252.47 x:584982.25 y:269251.22 x:584991.75 y:269248.66 x:584987.3 y:269234.03 x:584981.56 y:269218.12 x:584973.6 y:269208.56 x:584968.56 y:269202.84 x:584963.44 y:269198.06 x:584956.44 y:269194.25 x:584949.75 y:269191.7 x:584939.9 y:269189.16 x:584928.44 y:269188.84 x:584915.0 y:269192.56 x:584903.3 y:269197.5 x:584894.5 y:269201.34 x:584887.75 y:269205.16 x:584882.4 y:269206.28 x:584876.4 y:269206.6 x:584871.56 y:269206.72 x:584866.9 y:269205.38 x:584864.1 y:269202.5 x:584862.8 y:269197.28 x:584863.06 y:269189.62 x:584864.4 y:269180.88 x:584865.94 y:269173.38 x:584868.44 y:269162.88 x:584872.0 y:269151.38 x:584874.06 y:269139.9 x:584875.9 y:269128.9 x:584875.06 y:269115.2 x:584872.94 y:269103.28 x:584869.3 y:269089.78 x:584864.4 y:269077.62 x:584859.56 y:269066.53 x:584855.4 y:269060.78 x:584850.0 y:269056.06 x:584839.44 y:269051.78 x:584830.7 y:269050.66 Polygon4 x:584318.4 y:269092.28 x:584314.94 y:269098.5 x:584314.7 y:269109.0 x:584316.4 y:269118.34 x:584322.6 y:269129.4 x:584330.25 y:269136.47 x:584337.06 y:269142.72 x:584338.75 y:269149.5 x:584342.1 y:269166.78 x:584348.4 y:269178.12 x:584364.8 y:269190.56 x:584378.4 y:269195.7 x:584388.3 y:269200.5 x:584402.5 y:269210.97 x:584412.7 y:269214.94 x:584420.9 y:269216.9 x:584430.8 y:269216.9 x:584437.6 y:269216.06 x:584449.5 y:269214.66 x:584460.8 y:269214.94 x:584471.9 y:269212.38 x:584481.5 y:269208.12 x:584494.56 y:269203.3 x:584508.1 y:269195.12 x:584517.5 y:269183.78 x:584526.25 y:269169.62 x:584534.2 y:269151.22 x:584537.9 y:269143.0 x:584541.9 y:269137.03 x:584544.94 y:269129.7 x:584545.5 y:269120.62 x:584544.1 y:269114.66 x:584541.9 y:269111.53 x:584533.4 y:269107.6 x:584521.2 y:269105.6 x:584508.7 y:269104.75 x:584497.6 y:269105.03 x:584488.9 y:269104.2 x:584480.7 y:269103.62 x:584471.0 y:269103.34 x:584458.56 y:269104.75 x:584449.5 y:269107.0 x:584439.3 y:269109.0 x:584429.4 y:269109.28 x:584419.5 y:269110.97 x:584406.44 y:269110.7 x:584396.8 y:269108.44 x:584386.9 y:269104.47 x:584377.56 y:269099.94 x:584366.8 y:269095.4 x:584357.1 y:269090.6 x:584345.25 y:269088.03 x:584333.4 y:269087.47 x:584324.0 y:269089.44 x:584318.4 y:269092.28 Polygon5 x:584634.1 y:269182.97 x:584643.3 y:269186.34 x:584659.56 y:269186.84 x:584670.75 y:269183.94 x:584674.6 y:269180.34 x:584677.8 y:269175.78 x:584679.9 y:269167.6 x:584680.75 y:269158.47 x:584681.44 y:269144.56 x:584681.44 y:269133.84 x:584681.6 y:269123.22 x:584681.2 y:269113.56 x:584679.2 y:269100.6 x:584675.06 y:269088.7 x:584672.1 y:269084.4 x:584665.6 y:269081.78 x:584661.2 y:269081.0 x:584656.1 y:269081.66 x:584645.2 y:269084.2 x:584635.2 y:269088.06 x:584628.8 y:269091.94 x:584623.7 y:269095.44 x:584618.3 y:269105.6 x:584615.1 y:269120.62 x:584614.44 y:269135.7 x:584615.4 y:269147.53 x:584617.2 y:269156.66 x:584621.06 y:269166.9 x:584627.7 y:269177.38 x:584634.1 y:269182.97 5 polygons in total New unioned polygons New Polygon x:584676.8061638878 y:269177.221691886 x:584677.8125 y:269175.78125 x:584679.875 y:269167.59375 x:584680.75 y:269158.46875 x:584681.4375 y:269144.5625 x:584681.4375 y:269133.84375 x:584681.625 y:269123.21875 x:584681.1875 y:269113.5625 x:584679.1875 y:269100.59375 x:584675.0625 y:269088.6875 x:584672.125 y:269084.40625 x:584665.625 y:269081.78125 x:584661.1875 y:269081.0 x:584656.125 y:269081.65625 x:584645.1875 y:269084.1875 x:584635.1875 y:269088.0625 x:584628.8125 y:269091.9375 x:584623.6875 y:269095.4375 x:584618.3125 y:269105.59375 x:584617.8858171725 y:269107.60585235327 x:584617.6875 y:269106.53125 x:584614.9375 y:269098.8125 x:584609.5 y:269098.34375 x:584598.125 y:269100.1875 x:584587.625 y:269105.1875 x:584579.0 y:269112.90625 x:584575.375 y:269120.1875 x:584573.125 y:269131.5625 x:584572.625 y:269143.84375 x:584572.625 y:269156.09375 x:584574.4375 y:269169.28125 x:584574.9375 y:269183.375 x:584574.0 y:269198.40625 x:584569.9375 y:269214.3125 x:584565.8125 y:269229.78125 x:584559.0 y:269252.5 x:584557.1875 y:269264.34375 x:584555.375 y:269278.875 x:584558.125 y:269304.8125 x:584563.125 y:269323.0 x:584571.3125 y:269333.4375 x:584611.3125 y:269325.25 x:584620.75 y:269317.96875 x:584627.875 y:269310.53125 x:584632.9375 y:269302.8125 x:584637.6875 y:269297.4375 x:584642.1875 y:269293.28125 x:584646.625 y:269291.1875 x:584653.1875 y:269289.71875 x:584660.9375 y:269289.125 x:584671.3125 y:269288.8125 x:584679.0625 y:269289.40625 x:584685.875 y:269290.71875 x:584693.5 y:269292.40625 x:584698.75 y:269295.96875 x:584715.6875 y:269292.375 x:584718.25 y:269284.96875 x:584725.9375 y:269280.25 x:584732.1875 y:269280.46875 x:584738.0625 y:269283.84375 x:584751.375 y:269287.0625 x:584773.375 y:269277.46875 x:584780.375 y:269275.15625 x:584791.625 y:269275.5625 x:584799.0625 y:269275.5625 x:584806.0625 y:269276.625 x:584811.5625 y:269276.625 x:584823.4375 y:269273.65625 x:584833.8125 y:269272.125 x:584964.625 y:269254.8125 x:584973.3125 y:269252.46875 x:584982.25 y:269251.21875 x:584991.75 y:269248.65625 x:584987.3125 y:269234.03125 x:584981.5625 y:269218.125 x:584973.625 y:269208.5625 x:584968.5625 y:269202.84375 x:584963.4375 y:269198.0625 x:584956.4375 y:269194.25 x:584949.75 y:269191.6875 x:584939.875 y:269189.15625 x:584928.4375 y:269188.84375 x:584915.0 y:269192.5625 x:584903.3125 y:269197.5 x:584894.5 y:269201.34375 x:584887.75 y:269205.15625 x:584882.375 y:269206.28125 x:584876.375 y:269206.59375 x:584871.5625 y:269206.71875 x:584866.875 y:269205.375 x:584864.125 y:269202.5 x:584862.8125 y:269197.28125 x:584863.0625 y:269189.625 x:584864.375 y:269180.875 x:584865.9375 y:269173.375 x:584868.4375 y:269162.875 x:584872.0 y:269151.375 x:584874.0625 y:269139.90625 x:584875.875 y:269128.90625 x:584875.0625 y:269115.1875 x:584872.9375 y:269103.28125 x:584869.3125 y:269089.78125 x:584864.375 y:269077.625 x:584859.5625 y:269066.53125 x:584855.375 y:269060.78125 x:584850.0 y:269056.0625 x:584839.4375 y:269051.78125 x:584830.6875 y:269050.65625 x:584821.375 y:269051.53125 x:584812.875 y:269054.71875 x:584805.6875 y:269058.75 x:584799.1875 y:269063.71875 x:584794.125 y:269070.15625 x:584790.625 y:269078.78125 x:584787.0625 y:269091.375 x:584786.8125 y:269106.09375 x:584787.5 y:269125.5 x:584790.9375 y:269142.46875 x:584796.75 y:269154.34375 x:584802.375 y:269161.9375 x:584804.6875 y:269171.21875 x:584803.625 y:269178.84375 x:584802.125 y:269184.46875 x:584799.125 y:269187.9375 x:584794.6875 y:269190.78125 x:584790.0 y:269191.65625 x:584785.0625 y:269191.65625 x:584780.3125 y:269190.78125 x:584775.4375 y:269189.3125 x:584767.9375 y:269187.84375 x:584760.0625 y:269187.84375 x:584751.75 y:269188.53125 x:584745.9375 y:269190.09375 x:584739.1875 y:269193.0 x:584735.875 y:269195.65625 x:584732.1875 y:269198.625 x:584728.1875 y:269202.0 x:584723.625 y:269201.59375 x:584716.6875 y:269197.75 x:584711.5 y:269193.25 x:584709.25 y:269188.75 x:584703.0 y:269183.34375 x:584693.3125 y:269178.625 x:584684.0625 y:269176.8125 x:584676.8061638878 y:269177.221691886 x:584634.125 y:269182.96875 x:584643.3125 y:269186.34375 x:584655.7493115657 y:269186.7264211251 x:584652.5 y:269190.15625 x:584645.625 y:269199.65625 x:584640.375 y:269204.25 x:584633.1875 y:269205.5625 x:584626.3125 y:269202.9375 x:584622.1875 y:269192.03125 x:584619.9375 y:269181.5625 x:584619.9375 y:269171.125 x:584620.5049099702 y:269165.4313344372 x:584621.0625 y:269166.90625 x:584627.6875 y:269177.375 x:584634.125 y:269182.96875 x:584453.0131577031 y:269106.12776774267 x:584456.6875 y:269098.3125 x:584458.5625 y:269089.9375 x:584460.4375 y:269083.90625 x:584463.9375 y:269070.875 x:584466.5 y:269060.40625 x:584463.0 y:269042.96875 x:584457.875 y:269036.71875 x:584450.6875 y:269032.28125 x:584440.75 y:269028.0 x:584429.75 y:269027.40625 x:584417.625 y:269028.34375 x:584404.375 y:269031.59375 x:584390.1875 y:269039.5 x:584377.875 y:269052.0625 x:584367.4375 y:269065.0625 x:584363.6875 y:269076.9375 x:584364.625 y:269087.375 x:584365.4219651138 y:269094.7154681533 x:584357.125 y:269090.59375 x:584345.25 y:269088.03125 x:584333.375 y:269087.46875 x:584324.0 y:269089.4375 x:584318.375 y:269092.28125 x:584314.9375 y:269098.5 x:584314.6875 y:269109.0 x:584316.375 y:269118.34375 x:584319.2839603997 y:269123.4926099075 x:584315.625 y:269121.90625 x:584302.125 y:269117.65625 x:584291.125 y:269115.375 x:584279.8125 y:269114.125 x:584260.3125 y:269116.59375 x:584233.375 y:269122.28125 x:584200.6875 y:269129.375 x:584179.6875 y:269135.40625 x:584151.4375 y:269143.5625 x:584126.5625 y:269154.1875 x:584103.0625 y:269166.0625 x:584082.4375 y:269195.5625 x:584068.875 y:269250.375 x:584069.5 y:269262.0 x:584073.375 y:269274.0625 x:584078.6875 y:269284.71875 x:584086.5 y:269294.625 x:584096.0 y:269302.84375 x:584108.125 y:269305.625 x:584124.8125 y:269305.28125 x:584142.5625 y:269302.4375 x:584156.75 y:269298.1875 x:584169.0625 y:269292.25 x:584176.1875 y:269286.84375 x:584186.125 y:269276.1875 x:584196.375 y:269262.34375 x:584209.5 y:269244.625 x:584220.375 y:269232.09375 x:584229.75 y:269229.03125 x:584243.1875 y:269225.46875 x:584254.0 y:269226.8125 x:584260.25 y:269234.6875 x:584266.625 y:269241.4375 x:584271.25 y:269252.78125 x:584270.1875 y:269262.71875 x:584265.875 y:269267.6875 x:584261.0625 y:269272.1875 x:584255.625 y:269283.625 x:584245.3125 y:269302.4375 x:584239.625 y:269322.3125 x:584237.1875 y:269336.125 x:584238.0625 y:269345.3125 x:584237.875 y:269354.21875 x:584233.625 y:269369.46875 x:584224.75 y:269377.28125 x:584219.75 y:269384.71875 x:584218.375 y:269392.53125 x:584218.375 y:269404.21875 x:584232.75 y:269422.53125 x:584299.375 y:269394.25 x:584393.125 y:269373.59375 x:584397.125 y:269369.125 x:584401.0625 y:269363.4375 x:584403.1875 y:269349.96875 x:584400.3125 y:269330.46875 x:584393.5625 y:269312.0 x:584384.6875 y:269297.125 x:584374.875 y:269280.4375 x:584372.375 y:269268.75 x:584367.75 y:269248.53125 x:584362.4375 y:269234.0 x:584358.9375 y:269219.125 x:584355.6875 y:269208.8125 x:584354.3125 y:269194.96875 x:584353.0873829721 y:269181.6906433896 x:584364.8125 y:269190.5625 x:584378.375 y:269195.6875 x:584388.3125 y:269200.5 x:584402.5 y:269210.96875 x:584412.6875 y:269214.9375 x:584420.875 y:269216.90625 x:584430.8125 y:269216.90625 x:584437.625 y:269216.0625 x:584449.5 y:269214.65625 x:584460.8125 y:269214.9375 x:584471.875 y:269212.375 x:584481.5 y:269208.125 x:584494.5625 y:269203.3125 x:584508.125 y:269195.125 x:584517.5 y:269183.78125 x:584526.25 y:269169.625 x:584534.1875 y:269151.21875 x:584537.875 y:269143.0 x:584541.875 y:269137.03125 x:584544.9375 y:269129.6875 x:584545.5 y:269120.625 x:584544.125 y:269114.65625 x:584541.875 y:269111.53125 x:584533.375 y:269107.59375 x:584521.1875 y:269105.59375 x:584508.6875 y:269104.75 x:584497.625 y:269105.03125 x:584488.875 y:269104.1875 x:584480.6875 y:269103.625 x:584471.0 y:269103.34375 x:584458.5625 y:269104.75 x:584453.0131577031 y:269106.12776774267 1 polygon 
From: Anben PANGLOSE <benpolice@ho...>  20130808 15:33:30

Ok I see, i am trying to modify the code to achieve my goal, i will post my solution if I got something working... I need to study the source code deeper... Anyway thank you for your help. Anben. From: Landon Blake Sent: Thursday, August 8, 2013 4:55 PM To: jtstoposuiteuser@... Subject: Re: [Jtstoposuiteuser] Buffer operation with linestring, variable distance per segment Anben: Let me know if you decide to attempt this. I might be able to offer some suggestions and help. Landon On Thu, Aug 8, 2013 at 7:20 AM, Martin Davis <mtnclimb@...> wrote: As I said in that note, this is theoretically possible, with some careful and somewhat geometrically complex coding. Unfortunately this hasn't been done yet. In order to make this change you're going to need to fully understand how the OffsetCurveBuilder code works. At that point you should be able to determine how to modify it yourself. On 8/8/2013 6:17 AM, Anben PANGLOSE wrote: I found a old thread talking about that I think: http://sourceforge.net/mailarchive/message.php?msg_id=25822538 ([Jtstoposuiteuser] Buffer for LineString with different buffer values for each side of) Dr JTS said it was feasible using spiral? Is it the same problem? I am using the buffer operation to convert simple lines into walls. Each segment of the linestring is a wall, and each wall can have its own thickness. My problem are the joints and the end caps that JTS handle very brillantly. I thaught it would be possible to change the algorithm used in JTS to consider a different distance parameter for each segment in the linestring. Where in the code do I have to change the _distance variable to achieve my goal? @Landon Blake: I cannot split my input linestring into smaller chunks and then buffer eash segment, because I need the joint between each segment. After the merging of all the resulting polygon I will not have nice joints. Anben. From: Landon Blake Sent: Thursday, August 8, 2013 2:51 PM To: Anben PANGLOSE Subject: Re: [Jtstoposuiteuser] Buffer operation with linestring, variable distance per segment Anben: I'm pretty sure JTS doesn't do this out of the box. One work around would be to split your input linestring into smaller chunks based on the buffer widths. Then buffer them independently and merge the resulting polygons. Landon On Thu, Aug 8, 2013 at 3:25 AM, Anben PANGLOSE <benpolice@...> wrote: Hello, first of all thank you for this wonderful tool! i am using the c# port of JTS. I am new to JTS and i am trying to use the BufferBuilder class to compute polygon from linestring. It works like a charm, my problem is: Is there any way to compute the buffer from linestring but instead of using a constant distance, I would like to associate a distance per segment in the linestring (so that the distance parameter in the buffer operation is not a global parameter but associated with a segment). To illustrate: input: LINESTRING (90 480, 90 290, 320 290) (it’s a simple L) output with the buffer operation with a distance = 20: POLYGON ((110 310, 320 310, 340 310, 340 270, 70 270, 70 480, 70 500, 110 500, 110 310)) I would like for example to specify to BufferBuilder that the vertical part of the L have a distance = 20, and that the horizontal part of the L has a distance = 10 to have this output: POLYGON ((110 300, 320 300, 340 300, 340 280, 70 280, 70 480, 70 500, 110 500, 110 300)) Do you think this is possible? I am trying to modify the OffsetCurveBuilder class but without any success, can someone help me? Where to start? Thanks in advance and excuse my poor english, i speak french... Anben.  Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to codelevel detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Jtstoposuiteuser mailing list Jtstoposuiteuser@... https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser  Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to codelevel detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Jtstoposuiteuser mailing list Jtstoposuiteuser@... https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser No virus found in this message. Checked by AVG  http://www.avg.com Version: 2013.0.3392 / Virus Database: 3209/6557  Release Date: 08/06/13  Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to codelevel detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Jtstoposuiteuser mailing list Jtstoposuiteuser@... https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser   Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to codelevel detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk  _______________________________________________ Jtstoposuiteuser mailing list Jtstoposuiteuser@... https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser 
From: Landon Blake <sunburned.surveyor@gm...>  20130808 14:55:46

Anben: Let me know if you decide to attempt this. I might be able to offer some suggestions and help. Landon On Thu, Aug 8, 2013 at 7:20 AM, Martin Davis <mtnclimb@...> wrote: > As I said in that note, this is theoretically possible, with some careful > and somewhat geometrically complex coding. Unfortunately this hasn't been > done yet. > > In order to make this change you're going to need to fully understand how > the OffsetCurveBuilder code works. At that point you should be able to > determine how to modify it yourself. > > > On 8/8/2013 6:17 AM, Anben PANGLOSE wrote: > > I found a old thread talking about that I think: > http://sourceforge.net/mailarchive/message.php?msg_id=25822538 > > *([Jtstoposuiteuser] Buffer for LineString with different buffer > values for each side of)* > ** > Dr JTS said it was feasible using spiral? Is it the same problem? > I am using the buffer operation to convert simple lines into walls. Each > segment of the linestring is a wall, and each wall can have its own > thickness. My problem are the joints and the end caps that JTS handle very > brillantly. I thaught it would be possible to change the algorithm used in > JTS to consider a different distance parameter for each segment in the > linestring. > > Where in the code do I have to change the _distance variable to achieve > my goal? > > @Landon Blake: I cannot split my input linestring into smaller chunks > and then buffer eash segment, because I need the joint between each > segment. After the merging of all the resulting polygon I will not have > nice joints. > > Anben. > > > *From:* Landon Blake <sunburned.surveyor@...> > *Sent:* Thursday, August 8, 2013 2:51 PM > *To:* Anben PANGLOSE <benpolice@...> > *Subject:* Re: [Jtstoposuiteuser] Buffer operation with linestring, > variable distance per segment > > Anben: > > I'm pretty sure JTS doesn't do this out of the box. One work around would > be to split your input linestring into smaller chunks based on the buffer > widths. Then buffer them independently and merge the resulting polygons. > > Landon > > > On Thu, Aug 8, 2013 at 3:25 AM, Anben PANGLOSE <benpolice@...>wrote: > >> Hello, first of all thank you for this wonderful tool! i am using the >> c# port of JTS. I am new to JTS and i am trying to use the BufferBuilder >> class to compute polygon from linestring. It works like a charm, my problem >> is: Is there any way to compute the buffer from linestring but instead of >> using a constant distance, I would like to associate a distance per segment >> in the linestring (so that the distance parameter in the buffer operation >> is not a global parameter but associated with a segment). >> To illustrate: >> >> input: >> LINESTRING (90 480, 90 290, 320 290) >> (it’s a simple L) >> >> output with the buffer operation with a distance = 20: >> POLYGON ((110 310, 320 310, 340 310, 340 270, 70 270, 70 480, 70 500, 110 >> 500, 110 310)) >> >> I would like for example to specify to BufferBuilder that the vertical >> part of the L have a distance = 20, and that the horizontal part of the L >> has a distance = 10 to have this output: >> POLYGON ((110 300, 320 300, 340 300, 340 280, 70 280, 70 480, 70 500, 110 >> 500, 110 300)) >> >> Do you think this is possible? I am trying to modify the >> OffsetCurveBuilder class but without any success, can someone help me? >> Where to start? >> >> Thanks in advance and excuse my poor english, i speak french... >> >> Anben. >> >> >>  >> Get 100% visibility into Java/.NET code with AppDynamics Lite! >> It's a free troubleshooting tool designed for production. >> Get down to codelevel detail for bottlenecks, with <2% overhead. >> Download for free and get started troubleshooting in minutes. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Jtstoposuiteuser mailing list >> Jtstoposuiteuser@... >> https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser >> >> > > >  > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to codelevel detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Jtstoposuiteuser mailing listJtstoposuiteuser@...nethttps://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > > No virus found in this message. > Checked by AVG  http://www.avg.com > Version: 2013.0.3392 / Virus Database: 3209/6557  Release Date: 08/06/13 > > > > >  > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to codelevel detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > 
From: Martin Davis <mtnclimb@te...>  20130808 14:21:02

As I said in that note, this is theoretically possible, with some careful and somewhat geometrically complex coding. Unfortunately this hasn't been done yet. In order to make this change you're going to need to fully understand how the OffsetCurveBuilder code works. At that point you should be able to determine how to modify it yourself. On 8/8/2013 6:17 AM, Anben PANGLOSE wrote: > I found a old thread talking about that I think: > http://sourceforge.net/mailarchive/message.php?msg_id=25822538 > *([Jtstoposuiteuser] Buffer for LineString with different buffer > values for each side of)* > ** > Dr JTS said it was feasible using spiral? Is it the same problem? > I am using the buffer operation to convert simple lines into walls. > Each segment of the linestring is a wall, and each wall can have its > own thickness. My problem are the joints and the end caps that JTS > handle very brillantly. I thaught it would be possible to change the > algorithm used in JTS to consider a different distance parameter for > each segment in the linestring. > Where in the code do I have to change the _distance variable to > achieve my goal? > @Landon Blake: I cannot split my input linestring into smaller chunks > and then buffer eash segment, because I need the joint between each > segment. After the merging of all the resulting polygon I will not > have nice joints. > Anben. > *From:* Landon Blake <mailto:sunburned.surveyor@...> > *Sent:* Thursday, August 8, 2013 2:51 PM > *To:* Anben PANGLOSE <mailto:benpolice@...> > *Subject:* Re: [Jtstoposuiteuser] Buffer operation with linestring, > variable distance per segment > Anben: > I'm pretty sure JTS doesn't do this out of the box. One work around > would be to split your input linestring into smaller chunks based on > the buffer widths. Then buffer them independently and merge the > resulting polygons. > Landon > > > On Thu, Aug 8, 2013 at 3:25 AM, Anben PANGLOSE <benpolice@... > <mailto:benpolice@...>> wrote: > > Hello, first of all thank you for this wonderful tool! i am using > the c# port of JTS. I am new to JTS and i am trying to use the > BufferBuilder class to compute polygon from linestring. It works > like a charm, my problem is: Is there any way to compute the > buffer from linestring but instead of using a constant distance, I > would like to associate a distance per segment in the linestring > (so that the distance parameter in the buffer operation is not a > global parameter but associated with a segment). > To illustrate: > input: > LINESTRING (90 480, 90 290, 320 290) > (it’s a simple L) > output with the buffer operation with a distance = 20: > POLYGON ((110 310, 320 310, 340 310, 340 270, 70 270, 70 480, 70 > 500, 110 500, 110 310)) > I would like for example to specify to BufferBuilder that the > vertical part of the L have a distance = 20, and that the > horizontal part of the L has a distance = 10 to have this output: > POLYGON ((110 300, 320 300, 340 300, 340 280, 70 280, 70 480, 70 > 500, 110 500, 110 300)) > Do you think this is possible? I am trying to modify the > OffsetCurveBuilder class but without any success, can someone help > me? Where to start? > Thanks in advance and excuse my poor english, i speak french... > Anben. > >  > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to codelevel detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > <mailto:Jtstoposuiteuser@...> > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > >  > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to codelevel detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > > > _______________________________________________ > Jtstoposuiteuser mailing list > Jtstoposuiteuser@... > https://lists.sourceforge.net/lists/listinfo/jtstoposuiteuser > > > No virus found in this message. > Checked by AVG  http://www.avg.com <http://www.avg.com>; > Version: 2013.0.3392 / Virus Database: 3209/6557  Release Date: 08/06/13 > 
From: Martin Davis <mtnclimb@te...>  20130808 14:16:10

That seems odd, alright. Can you provide some actual data that demonstrates the problem? Otherwise it's hard to say what's going on, and impossible to provide a fix. On 8/8/2013 2:14 AM, Richmond, Tanya wrote: > Hi, > Would you be able to help me with a problem I have with unioning > polygons? I am trying to union polygons that contain holes and I know > this should work, as I have read previous entries on the forum, but no > matter what I try, it does not work for me. > When I am unioning polygons, this may result in one, two or more > polygons, some of which may contain holes. > Here is a picture of what I am trying to union: > I am trying to merge the brown areas into single polygons, so, you can > see that should result in two polygons, one of which contains a hole. > What I get is this: > The grey areas are the new polygons, but you can see that it has > inserted extra holes and created a link between the polygons, where > there shouldn't be one. > I have tried three different approaches  firstly, I iterated > repeatedly through all the polygons, unioning them where there was an > intersect. Secondly, I tried adding them to a collection, setting the > buffer to zero and doing a collective union. Third, I tried using the > CascadedPolygonUnion command and the above picture is the result of > that. The other two approaches gave slightly different results, but > none of them worked correctly. > Are you able to offer any alternative suggestions? > Many thanks > 