How to approach the DouglasPeuckerSimplifier treatment of polygons with holes which degenerate

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to approach the DouglasPeuckerSimplifier treatment of polygons with holes which degenerate

Rory Plaire
Hi all,
 
I'm running a DP simplification on a multipolygon. At least one of these polygons has a hole which degenerates into a linestring when simplifying. DPTransform then creates a GeometryCollection containing the shell as a LinearRing and the hole as a LineString. The DP transform then performs a Buffer(0.0) to create a valid geometry. The buffer discards both the degenerate hole (this is fine - it's ok if the hole disappears) as well as the LinearRing shell, since it is treated the same as a LineString in the Buffer(0.0) operation, and is also discarded.
 
I've been considering the best approach to how to get the DP to preserve the shell. It seems that both Buffer and DP collude here to kill my polygon (DP creates the GeometryCollection w/o converting the LinearRing back into a Polygon, and Buffer doesn't treat LinearRing differently than LineString), but are just relying on nominal heuristics to compute the geometry.
 
Mostly, I'm curious why DP doesn't try to preserve polygons in this case, and perhaps why Buffer doesn't treat a LinearRing as bufferable. I'd go ahead and make whatever changes I'd need to compute the geometries like I want, but I feel I'm missing something, and perhaps my approach would reflect that ignorance.
 
Anyone have insights they'd like to share?
 
Thanks!

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to approach the DouglasPeuckerSimplifier treatment of polygons with holes which degenerate

Martin Davis
Rory,

The conversion of the original polygon shell to a LinearRing sounds like
a bug.  I think what *should* happen is that the Polygon shell should be
retained in a Polygon, which will then be processed correctly by buffer(0).

Can you post your failure case?

The buffering behaviour on LinearRings is correct - LinearRings are
linear features, and buffer is designed to always return a polygon.  
There is no way to validly represent a line as a polygon, so they are
removed from the output.   The root of the problem is the bug, not the
behaviour of buffer.

Martin

Rory Plaire wrote:

> Hi all,
>  
> I'm running a DP simplification on a multipolygon. At least one of
> these polygons has a hole which degenerates into a linestring when
> simplifying. DPTransform then creates a GeometryCollection containing
> the shell as a LinearRing and the hole as a LineString. The DP
> transform then performs a Buffer(0.0) to create a valid geometry. The
> buffer discards both the degenerate hole (this is fine - it's ok if
> the hole disappears) as well as the LinearRing shell, since it is
> treated the same as a LineString in the Buffer(0.0) operation, and is
> also discarded.
>  
> I've been considering the best approach to how to get the DP to
> preserve the shell. It seems that both Buffer and DP collude here to
> kill my polygon (DP creates the GeometryCollection w/o converting the
> LinearRing back into a Polygon, and Buffer doesn't treat LinearRing
> differently than LineString), but are just relying on nominal
> heuristics to compute the geometry.
>  
> Mostly, I'm curious why DP doesn't try to preserve polygons in this
> case, and perhaps why Buffer doesn't treat a LinearRing as bufferable.
> I'd go ahead and make whatever changes I'd need to compute the
> geometries like I want, but I feel I'm missing something, and perhaps
> my approach would reflect that ignorance.
>  
> Anyone have insights they'd like to share?
>  
> Thanks!
> ------------------------------------------------------------------------
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>  

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to approach the DouglasPeuckerSimplifier treatment of polygons with holes which degenerate

Rory Plaire
Hi Martin,
 
Thanks for the input.
 
The simplest case I can come up with is something like this: POLYGON((0 0, 0 4, 4 4, 4 0, 0 0), (1 1, 1 1.5, 1.5 1.5, 1 1)).
 
When we call DouglasPeuckerSimplifier.Simplify with a tolerance of 1, the hole will collapse, and in the DPTransformer specialization of GeometryTransformer, the transformPolygon method will be called, and internall the "isAllValidLinearRings" will be false, causing "factory.buildGeometry(components)" (line 229) to be invoked on a list of the LinearRing and the LineString. This results in a GeometryCollection, of course, which seems to be the right thing to do at this level of GeometryTransformer. Back up in the DPTransform, this result is passed along to Buffer(0.0) before I might be able to inspect it and perhaps weld together the linear ring and discard the line string, and Buffer dutifully discards both components and returns an empty geometry.
 
Thanks for taking a look!
 
-rory

On Tue, Dec 2, 2008 at 2:19 PM, Martin Davis <[hidden email]> wrote:
Rory,

The conversion of the original polygon shell to a LinearRing sounds like a bug.  I think what *should* happen is that the Polygon shell should be retained in a Polygon, which will then be processed correctly by buffer(0).

Can you post your failure case?

The buffering behaviour on LinearRings is correct - LinearRings are linear features, and buffer is designed to always return a polygon.  There is no way to validly represent a line as a polygon, so they are removed from the output.   The root of the problem is the bug, not the behaviour of buffer.

Martin

Rory Plaire wrote:
Hi all,
 I'm running a DP simplification on a multipolygon. At least one of these polygons has a hole which degenerates into a linestring when simplifying. DPTransform then creates a GeometryCollection containing the shell as a LinearRing and the hole as a LineString. The DP transform then performs a Buffer(0.0) to create a valid geometry. The buffer discards both the degenerate hole (this is fine - it's ok if the hole disappears) as well as the LinearRing shell, since it is treated the same as a LineString in the Buffer(0.0) operation, and is also discarded.
 I've been considering the best approach to how to get the DP to preserve the shell. It seems that both Buffer and DP collude here to kill my polygon (DP creates the GeometryCollection w/o converting the LinearRing back into a Polygon, and Buffer doesn't treat LinearRing differently than LineString), but are just relying on nominal heuristics to compute the geometry.
 Mostly, I'm curious why DP doesn't try to preserve polygons in this case, and perhaps why Buffer doesn't treat a LinearRing as bufferable. I'd go ahead and make whatever changes I'd need to compute the geometries like I want, but I feel I'm missing something, and perhaps my approach would reflect that ignorance.
 Anyone have insights they'd like to share?
 Thanks!
------------------------------------------------------------------------

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
 

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel


_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to approach the DouglasPeuckerSimplifier treatment of polygons with holes which degenerate

Martin Davis
Rory,

This was a bug in JTS 1.9 - it's fixed in JTS 1.10.  There's an alpha
release of this at http://tsusiatsoftware.net/jts/files/jts-1.10-alpha2.zip

Rory Plaire wrote:

> Hi Martin,
>  
> Thanks for the input.
>  
> The simplest case I can come up with is something like this:
> POLYGON((0 0, 0 4, 4 4, 4 0, 0 0), (1 1, 1 1.5, 1.5 1.5, 1 1)).
>  
> When we call DouglasPeuckerSimplifier.Simplify with a tolerance of 1,
> the hole will collapse, and in the DPTransformer specialization of
> GeometryTransformer, the transformPolygon method will be called, and
> internall the "isAllValidLinearRings" will be false, causing
> "factory.buildGeometry(components)" (line 229) to be invoked on a list
> of the LinearRing and the LineString. This results in a
> GeometryCollection, of course, which seems to be the right thing to do
> at this level of GeometryTransformer. Back up in the DPTransform, this
> result is passed along to Buffer(0.0) before I might be able to
> inspect it and perhaps weld together the linear ring and discard the
> line string, and Buffer dutifully discards both components and returns
> an empty geometry.
>  
> Thanks for taking a look!
>  
> -rory
>
> On Tue, Dec 2, 2008 at 2:19 PM, Martin Davis <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Rory,
>
>     The conversion of the original polygon shell to a LinearRing
>     sounds like a bug.  I think what *should* happen is that the
>     Polygon shell should be retained in a Polygon, which will then be
>     processed correctly by buffer(0).
>
>     Can you post your failure case?
>
>     The buffering behaviour on LinearRings is correct - LinearRings
>     are linear features, and buffer is designed to always return a
>     polygon.  There is no way to validly represent a line as a
>     polygon, so they are removed from the output.   The root of the
>     problem is the bug, not the behaviour of buffer.
>
>     Martin
>
>     Rory Plaire wrote:
>
>         Hi all,
>          I'm running a DP simplification on a multipolygon. At least
>         one of these polygons has a hole which degenerates into a
>         linestring when simplifying. DPTransform then creates a
>         GeometryCollection containing the shell as a LinearRing and
>         the hole as a LineString. The DP transform then performs a
>         Buffer(0.0) to create a valid geometry. The buffer discards
>         both the degenerate hole (this is fine - it's ok if the hole
>         disappears) as well as the LinearRing shell, since it is
>         treated the same as a LineString in the Buffer(0.0) operation,
>         and is also discarded.
>          I've been considering the best approach to how to get the DP
>         to preserve the shell. It seems that both Buffer and DP
>         collude here to kill my polygon (DP creates the
>         GeometryCollection w/o converting the LinearRing back into a
>         Polygon, and Buffer doesn't treat LinearRing differently than
>         LineString), but are just relying on nominal heuristics to
>         compute the geometry.
>          Mostly, I'm curious why DP doesn't try to preserve polygons
>         in this case, and perhaps why Buffer doesn't treat a
>         LinearRing as bufferable. I'd go ahead and make whatever
>         changes I'd need to compute the geometries like I want, but I
>         feel I'm missing something, and perhaps my approach would
>         reflect that ignorance.
>          Anyone have insights they'd like to share?
>          Thanks!
>         ------------------------------------------------------------------------
>
>         _______________________________________________
>         jts-devel mailing list
>         [hidden email]
>         <mailto:[hidden email]>
>         http://lists.refractions.net/mailman/listinfo/jts-devel
>          
>
>
>     --
>     Martin Davis
>     Senior Technical Architect
>     Refractions Research, Inc.
>     (250) 383-3022
>
>     _______________________________________________
>     jts-devel mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.refractions.net/mailman/listinfo/jts-devel
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>  

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to approach the DouglasPeuckerSimplifier treatment of polygons with holes which degenerate

Rory Plaire
Thanks Martin,
 
If I read correctly, it appears that the bug fix was to override transformLinearRing and return null on a ring collapse... Am I missing anything?
 
-r

On Wed, Dec 3, 2008 at 9:15 AM, Martin Davis <[hidden email]> wrote:
Rory,

This was a bug in JTS 1.9 - it's fixed in JTS 1.10.  There's an alpha release of this at http://tsusiatsoftware.net/jts/files/jts-1.10-alpha2.zip

Rory Plaire wrote:
Hi Martin,
 Thanks for the input.
 The simplest case I can come up with is something like this: POLYGON((0 0, 0 4, 4 4, 4 0, 0 0), (1 1, 1 1.5, 1.5 1.5, 1 1)).
 When we call DouglasPeuckerSimplifier.Simplify with a tolerance of 1, the hole will collapse, and in the DPTransformer specialization of GeometryTransformer, the transformPolygon method will be called, and internall the "isAllValidLinearRings" will be false, causing "factory.buildGeometry(components)" (line 229) to be invoked on a list of the LinearRing and the LineString. This results in a GeometryCollection, of course, which seems to be the right thing to do at this level of GeometryTransformer. Back up in the DPTransform, this result is passed along to Buffer(0.0) before I might be able to inspect it and perhaps weld together the linear ring and discard the line string, and Buffer dutifully discards both components and returns an empty geometry.
 Thanks for taking a look!
 -rory

On Tue, Dec 2, 2008 at 2:19 PM, Martin Davis <[hidden email] <mailto:[hidden email]>> wrote:

   Rory,

   The conversion of the original polygon shell to a LinearRing
   sounds like a bug.  I think what *should* happen is that the
   Polygon shell should be retained in a Polygon, which will then be
   processed correctly by buffer(0).

   Can you post your failure case?

   The buffering behaviour on LinearRings is correct - LinearRings
   are linear features, and buffer is designed to always return a
   polygon.  There is no way to validly represent a line as a
   polygon, so they are removed from the output.   The root of the
   problem is the bug, not the behaviour of buffer.

   Martin

   Rory Plaire wrote:

       Hi all,
        I'm running a DP simplification on a multipolygon. At least
       one of these polygons has a hole which degenerates into a
       linestring when simplifying. DPTransform then creates a
       GeometryCollection containing the shell as a LinearRing and
       the hole as a LineString. The DP transform then performs a
       Buffer(0.0) to create a valid geometry. The buffer discards
       both the degenerate hole (this is fine - it's ok if the hole
       disappears) as well as the LinearRing shell, since it is
       treated the same as a LineString in the Buffer(0.0) operation,
       and is also discarded.
        I've been considering the best approach to how to get the DP
       to preserve the shell. It seems that both Buffer and DP
       collude here to kill my polygon (DP creates the
       GeometryCollection w/o converting the LinearRing back into a
       Polygon, and Buffer doesn't treat LinearRing differently than
       LineString), but are just relying on nominal heuristics to
       compute the geometry.
        Mostly, I'm curious why DP doesn't try to preserve polygons
       in this case, and perhaps why Buffer doesn't treat a
       LinearRing as bufferable. I'd go ahead and make whatever
       changes I'd need to compute the geometries like I want, but I
       feel I'm missing something, and perhaps my approach would
       reflect that ignorance.
        Anyone have insights they'd like to share?
        Thanks!
       ------------------------------------------------------------------------

       _______________________________________________
       jts-devel mailing list
       [hidden email]
       <mailto:[hidden email]>

       http://lists.refractions.net/mailman/listinfo/jts-devel
       

   --    Martin Davis
   Senior Technical Architect
   Refractions Research, Inc.
   (250) 383-3022

   _______________________________________________
   jts-devel mailing list
   [hidden email]
   <mailto:[hidden email]>

   http://lists.refractions.net/mailman/listinfo/jts-devel


------------------------------------------------------------------------

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
 

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel


_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to approach the DouglasPeuckerSimplifier treatment of polygons with holes which degenerate

Martin Davis
That sounds right.  A diff on the two versions of the file should
confirm.  It wasn't a major change.

Rory Plaire wrote:

> Thanks Martin,
>  
> If I read correctly, it appears that the bug fix was to override
> transformLinearRing and return null on a ring collapse... Am I missing
> anything?
>  
> -r
>
> On Wed, Dec 3, 2008 at 9:15 AM, Martin Davis <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Rory,
>
>     This was a bug in JTS 1.9 - it's fixed in JTS 1.10.  There's an
>     alpha release of this at
>     http://tsusiatsoftware.net/jts/files/jts-1.10-alpha2.zip
>
>     Rory Plaire wrote:
>
>         Hi Martin,
>          Thanks for the input.
>          The simplest case I can come up with is something like this:
>         POLYGON((0 0, 0 4, 4 4, 4 0, 0 0), (1 1, 1 1.5, 1.5 1.5, 1 1)).
>          When we call DouglasPeuckerSimplifier.Simplify with a
>         tolerance of 1, the hole will collapse, and in the
>         DPTransformer specialization of GeometryTransformer, the
>         transformPolygon method will be called, and internall the
>         "isAllValidLinearRings" will be false, causing
>         "factory.buildGeometry(components)" (line 229) to be invoked
>         on a list of the LinearRing and the LineString. This results
>         in a GeometryCollection, of course, which seems to be the
>         right thing to do at this level of GeometryTransformer. Back
>         up in the DPTransform, this result is passed along to
>         Buffer(0.0) before I might be able to inspect it and perhaps
>         weld together the linear ring and discard the line string, and
>         Buffer dutifully discards both components and returns an empty
>         geometry.
>          Thanks for taking a look!
>          -rory
>
>         On Tue, Dec 2, 2008 at 2:19 PM, Martin Davis
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>> wrote:
>
>            Rory,
>
>            The conversion of the original polygon shell to a LinearRing
>            sounds like a bug.  I think what *should* happen is that the
>            Polygon shell should be retained in a Polygon, which will
>         then be
>            processed correctly by buffer(0).
>
>            Can you post your failure case?
>
>            The buffering behaviour on LinearRings is correct - LinearRings
>            are linear features, and buffer is designed to always return a
>            polygon.  There is no way to validly represent a line as a
>            polygon, so they are removed from the output.   The root of the
>            problem is the bug, not the behaviour of buffer.
>
>            Martin
>
>            Rory Plaire wrote:
>
>                Hi all,
>                 I'm running a DP simplification on a multipolygon. At
>         least
>                one of these polygons has a hole which degenerates into a
>                linestring when simplifying. DPTransform then creates a
>                GeometryCollection containing the shell as a LinearRing and
>                the hole as a LineString. The DP transform then performs a
>                Buffer(0.0) to create a valid geometry. The buffer discards
>                both the degenerate hole (this is fine - it's ok if the
>         hole
>                disappears) as well as the LinearRing shell, since it is
>                treated the same as a LineString in the Buffer(0.0)
>         operation,
>                and is also discarded.
>                 I've been considering the best approach to how to get
>         the DP
>                to preserve the shell. It seems that both Buffer and DP
>                collude here to kill my polygon (DP creates the
>                GeometryCollection w/o converting the LinearRing back
>         into a
>                Polygon, and Buffer doesn't treat LinearRing
>         differently than
>                LineString), but are just relying on nominal heuristics to
>                compute the geometry.
>                 Mostly, I'm curious why DP doesn't try to preserve
>         polygons
>                in this case, and perhaps why Buffer doesn't treat a
>                LinearRing as bufferable. I'd go ahead and make whatever
>                changes I'd need to compute the geometries like I want,
>         but I
>                feel I'm missing something, and perhaps my approach would
>                reflect that ignorance.
>                 Anyone have insights they'd like to share?
>                 Thanks!
>              
>          ------------------------------------------------------------------------
>
>                _______________________________________________
>                jts-devel mailing list
>                [hidden email]
>         <mailto:[hidden email]>
>                <mailto:[hidden email]
>         <mailto:[hidden email]>>
>
>                http://lists.refractions.net/mailman/listinfo/jts-devel
>                
>
>            --    Martin Davis
>            Senior Technical Architect
>            Refractions Research, Inc.
>            (250) 383-3022
>
>            _______________________________________________
>            jts-devel mailing list
>            [hidden email]
>         <mailto:[hidden email]>
>            <mailto:[hidden email]
>         <mailto:[hidden email]>>
>
>            http://lists.refractions.net/mailman/listinfo/jts-devel
>
>
>         ------------------------------------------------------------------------
>
>         _______________________________________________
>         jts-devel mailing list
>         [hidden email]
>         <mailto:[hidden email]>
>         http://lists.refractions.net/mailman/listinfo/jts-devel
>          
>
>
>     --
>     Martin Davis
>     Senior Technical Architect
>     Refractions Research, Inc.
>     (250) 383-3022
>
>     _______________________________________________
>     jts-devel mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.refractions.net/mailman/listinfo/jts-devel
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jts-devel mailing list
> [hidden email]
> http://lists.refractions.net/mailman/listinfo/jts-devel
>  

--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
jts-devel mailing list
[hidden email]
http://lists.refractions.net/mailman/listinfo/jts-devel
Loading...