Thanks Stefan. Your method is efficient.
Cheers Brian
On Sun, Oct 14, 2012 at 10:07 PM, <
jts-topo-suite-user-request@...> wrote:
> Send Jts-topo-suite-user mailing list submissions to
> jts-topo-suite-user@...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
> or, via email, send a message with subject or body 'help' to
> jts-topo-suite-user-request@...
>
> You can reach the person managing the list at
> jts-topo-suite-user-owner@...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Jts-topo-suite-user digest..."
>
>
> Today's Topics:
>
> 1. Cache geometry graphs/nodes? (Shahak Nagiel)
> 2. Re: Cache geometry graphs/nodes? (Martin Davis)
> 3. Polygon buffering (Brian Sanjeewa Rupasinghe)
> 4. Re: Polygon buffering (Stefan Steiniger)
> 5. Re: Polygon buffering (Martin Davis)
> 6. Re: Polygon buffering (Martin Davis)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 10 Oct 2012 12:46:17 -0700 (PDT)
> From: Shahak Nagiel <snagiel@...>
> Subject: [Jts-topo-suite-user] Cache geometry graphs/nodes?
> To: "jts-topo-suite-user@..."
> <jts-topo-suite-user@...>
> Message-ID:
> <1349898377.12245.YahooMailNeo@...>
> Content-Type: text/plain; charset="us-ascii"
>
> I'm processing a large volume of records, in which I perform
> IntersectionMatrix calculations between geometry pairs via
> RelateOp.relate(geo1, geo2).matches(...).
>
>
> Some of these geometries are relatively large/complex (multipolygons with
> several thousand points), but we keep processing them repeatedly.
>
> Poking (a little) into the code, it looks the relate() method builds up
> GeometryGraph's for both geo's, then passes them off to a RelateComputer,
> which computes nodes and so forth.
>
> I'm wondering whether there's some trick for pre-processing (compiling?) a
> geometry's graph/nodes to expedite this processing (i.e. avoid having to
> re-compute these graphs/nodes repeatedly and just do the minimal work of
> computing edge intersections)?
>
> Thanks!
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Wed, 10 Oct 2012 13:40:05 -0700
> From: Martin Davis <mtnclimb@...>
> Subject: Re: [Jts-topo-suite-user] Cache geometry graphs/nodes?
> Cc: "jts-topo-suite-user@..."
> <jts-topo-suite-user@...>
> Message-ID:
> <CAK2ens0_qLDdxfBcTehDg8xULqvKCBRsH9=
> yKr2ZHEWb2nX4KA@...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> This is certainly theoretically possible, but it requires a
> substantial rework of the current relate algorithm. I've recently
> been thinking about this exact problem, and have a conceptual design
> for how to address this issue (and some other ones as well, such a
> small robustness problem that cropped up in the last few months).
>
> However, this work will take a significant effort, so it probably
> won't get done until there's some funding to support it.
>
> In the meantime, you can use the PreparedGeometry API to improve the
> performance of some of the more common predicates, such as intersects,
> contains, and covers.
>
> On Wed, Oct 10, 2012 at 12:46 PM, Shahak Nagiel <snagiel@...> wrote:
> > I'm processing a large volume of records, in which I perform
> > IntersectionMatrix calculations between geometry pairs via
> > RelateOp.relate(geo1, geo2).matches(...).
> >
> > Some of these geometries are relatively large/complex (multipolygons with
> > several thousand points), but we keep processing them repeatedly.
> >
> > Poking (a little) into the code, it looks the relate() method builds up
> > GeometryGraph's for both geo's, then passes them off to a RelateComputer,
> > which computes nodes and so forth.
> >
> > I'm wondering whether there's some trick for pre-processing (compiling?)
> a
> > geometry's graph/nodes to expedite this processing (i.e. avoid having to
> > re-compute these graphs/nodes repeatedly and just do the minimal work of
> > computing edge intersections)?
> >
> > Thanks!
> >
> >
> ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> > _______________________________________________
> > Jts-topo-suite-user mailing list
> > Jts-topo-suite-user@...
> > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 14 Oct 2012 12:37:34 +0100
> From: Brian Sanjeewa Rupasinghe <jinkabs@...>
> Subject: [Jts-topo-suite-user] Polygon buffering
> To: jts-topo-suite-user@...
> Message-ID:
> <CAEMA-4iAC=
> jjOwo5XX7241Aa5uzUVz+ZNDLJ79b8sUZ65pVXyA@...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I have a polygon with a hole. When i apply a positive buffer using buffer
> builder on it, the hole disappeared when the buffer distance
> used larger than the maximum distance between two rings in the polygon. Is
> there any method to keep the inner ring intact irrespective
> of the buffer distance applied? I think this is possible by subtracting
> inner ring from the Buffered result. Any short-cut method within Buffer
> classes
> for this?
>
> Cheers, Brian.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: 14 Oct 2012 12:35:55 -0300
> From: "Stefan Steiniger" <sstein@...>
> Subject: Re: [Jts-topo-suite-user] Polygon buffering
> To: jts-topo-suite-user@...
> Message-ID: <507ADBDB.5060905@...>
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
>
> Hi,
>
> I would just rebuild the polygon by taking the outer shell/Exterior Ring
> from your buffered polygon and then take all the Inner Rings from the
> original poly. But of course based on a previous test if there actually
> are InnerRings.
>
> The behaviour, to buffer the inner rings, is by design and appears to me
> as it should be. Imagine for instance a polygon that is like an "O". So
> you want both sided buffered.
>
> cheers,
> stefan
>
> Am 14.10.12 08:37, schrieb Brian Sanjeewa Rupasinghe:
> > Hi,
> >
> > I have a polygon with a hole. When i apply a positive buffer using
> > buffer builder on it, the hole disappeared when the buffer distance
> > used larger than the maximum distance between two rings in the polygon.
> > Is there any method to keep the inner ring intact irrespective
> > of the buffer distance applied? I think this is possible by subtracting
> > inner ring from the Buffered result. Any short-cut method within Buffer
> > classes
> > for this?
> >
> > Cheers, Brian.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> >
> >
> >
> > _______________________________________________
> > Jts-topo-suite-user mailing list
> > Jts-topo-suite-user@...
> > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
> >
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 14 Oct 2012 10:18:55 -0700
> From: Martin Davis <mtnclimb@...>
> Subject: Re: [Jts-topo-suite-user] Polygon buffering
> To: Brian Sanjeewa Rupasinghe <jinkabs@...>
> Cc: jts-topo-suite-user@...
> Message-ID:
> <CAK2ens1V-b+RBmsMgb8XTMAJqCj44ks9VVDZ1=
> NUnizkbLpw7g@...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Right now the only way to do this is by manually copying the holes
> from the input polygon to the buffered polygon.
>
> There's been a suggestion that this should be added to the
> Single-Sided Buffer functionality, which makes sense.
>
> On Sun, Oct 14, 2012 at 4:37 AM, Brian Sanjeewa Rupasinghe
> <jinkabs@...> wrote:
> > Hi,
> >
> > I have a polygon with a hole. When i apply a positive buffer using buffer
> > builder on it, the hole disappeared when the buffer distance
> > used larger than the maximum distance between two rings in the polygon.
> Is
> > there any method to keep the inner ring intact irrespective
> > of the buffer distance applied? I think this is possible by subtracting
> > inner ring from the Buffered result. Any short-cut method within Buffer
> > classes
> > for this?
> >
> > Cheers, Brian.
> >
> >
> ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> > _______________________________________________
> > Jts-topo-suite-user mailing list
> > Jts-topo-suite-user@...
> > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 14 Oct 2012 14:07:12 -0700
> From: Martin Davis <mtnclimb@...>
> Subject: Re: [Jts-topo-suite-user] Polygon buffering
> To: Brian Sanjeewa Rupasinghe <jinkabs@...>
> Cc: jts-topo-suite-user@...
> Message-ID:
> <
> CAK2ens22aEQYkvAeN+4HpBrEL8j8VMcoJNp47o0F4KUdTQhfyg@...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> By "manually" I mean write the small amount of code to copy the holes
> from the input polygon and add them to the buffer polygon.
>
> If by "subtract" you mean the difference method, you can do it that
> way too, but it will be slower.
>
> On Sun, Oct 14, 2012 at 11:19 AM, Brian Sanjeewa Rupasinghe
> <jinkabs@...> wrote:
> > Thanks. Why manually copying? Is it not possible to get the inner holes
> and
> > subtract them from the buffered polygon?
> >
> >
> > On Sun, Oct 14, 2012 at 6:18 PM, Martin Davis <mtnclimb@...>
> wrote:
> >>
> >> Right now the only way to do this is by manually copying the holes
> >> from the input polygon to the buffered polygon.
> >>
> >> There's been a suggestion that this should be added to the
> >> Single-Sided Buffer functionality, which makes sense.
> >>
> >> On Sun, Oct 14, 2012 at 4:37 AM, Brian Sanjeewa Rupasinghe
> >> <jinkabs@...> wrote:
> >> > Hi,
> >> >
> >> > I have a polygon with a hole. When i apply a positive buffer using
> >> > buffer
> >> > builder on it, the hole disappeared when the buffer distance
> >> > used larger than the maximum distance between two rings in the
> polygon.
> >> > Is
> >> > there any method to keep the inner ring intact irrespective
> >> > of the buffer distance applied? I think this is possible by
> subtracting
> >> > inner ring from the Buffered result. Any short-cut method within
> Buffer
> >> > classes
> >> > for this?
> >> >
> >> > Cheers, Brian.
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Don't let slow site performance ruin your business. Deploy New Relic
> APM
> >> > Deploy New Relic app performance management and know exactly
> >> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> >> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> >> > http://p.sf.net/sfu/newrelic-dev2dev
> >> > _______________________________________________
> >> > Jts-topo-suite-user mailing list
> >> > Jts-topo-suite-user@...
> >> > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
> >> >
> >
> >
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
> ------------------------------
>
> _______________________________________________
> Jts-topo-suite-user mailing list
> Jts-topo-suite-user@...
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>
>
> End of Jts-topo-suite-user Digest, Vol 34, Issue 3
> **************************************************
>
|