PolygonRectifier?

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

PolygonRectifier?

Stefan Steiniger
Hei

just a note: JUMP/OpenJUMP has a couple of tools for assessing
geometries (Tools/QA menu). There is also a plugin that contains some
classes from the Java Conflation Suite (
http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=243601 
)

could be that some tools/code are useful for your tasks

stefan
_______________________________________________
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: PolygonRectifier?

Tuure Laurinolli
Stefan Steiniger wrote:
> Hei
>
> just a note: JUMP/OpenJUMP has a couple of tools for assessing
> geometries (Tools/QA menu). There is also a plugin that contains some
> classes from the Java Conflation Suite (
> http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=243601 
> )

> could be that some tools/code are useful for your tasks

I have used the tools in OpenJUMP to find out what's wrong with some
broken geometries, and to fix them by hand. This usually works
beautifully, but OpenJUMP doesn't deal with some oddly broken
geometries. IIRC the problematic ones were polygons with holes that have
wrong orientation.
_______________________________________________
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: PolygonRectifier?

Sunburned Surveyor
Tuure,

You wrote: "...OpenJUMP doesn't deal with some oddly broken geometries..."

What are you trying to do with these geometries and how are they broken?

The Sunburned Surveyor

On Wed, Feb 4, 2009 at 5:20 PM, Tuure Laurinolli
<[hidden email]> wrote:

> Stefan Steiniger wrote:
>>
>> Hei
>>
>> just a note: JUMP/OpenJUMP has a couple of tools for assessing geometries
>> (Tools/QA menu). There is also a plugin that contains some classes from the
>> Java Conflation Suite (
>> http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=243601
>> )
>
>> could be that some tools/code are useful for your tasks
>
> I have used the tools in OpenJUMP to find out what's wrong with some broken
> geometries, and to fix them by hand. This usually works beautifully, but
> OpenJUMP doesn't deal with some oddly broken geometries. IIRC the
> problematic ones were polygons with holes that have wrong orientation.
> _______________________________________________
> 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: PolygonRectifier?

Larry Becker
Michael has ported over my shapefile read modification to OJ that detects clockwise oriented linear rings that are inside other linear rings and interpret this as a hole.  This was done in May 2008.  If there is a case that it doesn't handle, please post the example in WKT format.

Larry

On Tue, Feb 10, 2009 at 9:21 AM, Sunburned Surveyor <[hidden email]> wrote:
Tuure,

You wrote: "...OpenJUMP doesn't deal with some oddly broken geometries..."

What are you trying to do with these geometries and how are they broken?

The Sunburned Surveyor

On Wed, Feb 4, 2009 at 5:20 PM, Tuure Laurinolli
<[hidden email]> wrote:
> Stefan Steiniger wrote:
>>
>> Hei
>>
>> just a note: JUMP/OpenJUMP has a couple of tools for assessing geometries
>> (Tools/QA menu). There is also a plugin that contains some classes from the
>> Java Conflation Suite (
>> http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=243601
>> )
>
>> could be that some tools/code are useful for your tasks
>
> I have used the tools in OpenJUMP to find out what's wrong with some broken
> geometries, and to fix them by hand. This usually works beautifully, but
> OpenJUMP doesn't deal with some oddly broken geometries. IIRC the
> problematic ones were polygons with holes that have wrong orientation.
> _______________________________________________
> 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



--
http://amusingprogrammer.blogspot.com/

_______________________________________________
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: PolygonRectifier?

Tuure Laurinolli
I think the last time I used OJ with the broken geometries was in early
2008, thus before the fixes. If I'll ever have to deal with them again I
will report in more detail.

Larry Becker wrote:
> Michael has ported over my shapefile read modification to OJ that detects
> clockwise oriented linear rings that are inside other linear rings and
> interpret this as a hole.  This was done in May 2008.  If there is a case
> that it doesn't handle, please post the example in WKT format.
_______________________________________________
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: PolygonRectifier?

Tuure Laurinolli
In reply to this post by Sunburned Surveyor
Sunburned Surveyor wrote:
> Tuure,
>
> You wrote: "...OpenJUMP doesn't deal with some oddly broken geometries..."
>
> What are you trying to do with these geometries and how are they broken?

With OpenJUMP I was trying to see if the invalid geometries were
important enough to be salvaged, or if I could just drop them. This was
part of preprocessing to get a Shape reader to accept them for
conversion into a proprietary format. The converter read even the
invalid geometries in fine, but at later stages of conversion there were
problems - thus I had to find and either drop or fix invalid geometries
in the early stages of conversion.

Usually the problematic geometries had self-intersections and duplicate
points, but some were stranger and had e.g. those inverted rings I
mentioned before.
_______________________________________________
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: PolygonRectifier?

azabala
The problem is that OpenJUMP uses JTS as geometry model, and JTS is a restrictive geometry model, based in SFS OGC specification.
This specification says "polygons shells must not have self-intersections", so when JTS finds this kind of geometry launchs an exception (TopologyException).

Other projects, like gvSIG, Geotools, etc. use a less restrictive geometry model: Java2D, for rendering geometries. So when the persistence driver reads a self-intersecting polygon shell, it doesnt create a JTS polygon, it creates a Java2D GeneralPath, geometry model which allows self-intersecting polygons.

In my opinion, one of the points where JTS could improve in this subject is not to "short-cuit" validation in isValid() geometry method. This method, when find an error, launchs an exception, so you need many iterations to correct a geometry at all.

I have developed a Quality Assurance library for gvSIG project: libTopology [1], to ensure topological correctness with a rule based model. Im planning to port this library to GeoAPI (in medium term, not before the final of 2009 for overworking :(  ), to allow geometry validations. I have desglosed all isValid validations in multiple steps [2]. This, of course, is only a proof of concepts.

[1] libTopology. http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/
[2] Decompsing isValid(). http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/src/org/gvsig/topology/topologyrules/JtsValidRule.java
2009/2/12 Tuure Laurinolli <[hidden email]>
Sunburned Surveyor wrote:
Tuure,

You wrote: "...OpenJUMP doesn't deal with some oddly broken geometries..."

What are you trying to do with these geometries and how are they broken?

With OpenJUMP I was trying to see if the invalid geometries were important enough to be salvaged, or if I could just drop them. This was part of preprocessing to get a Shape reader to accept them for conversion into a proprietary format. The converter read even the invalid geometries in fine, but at later stages of conversion there were problems - thus I had to find and either drop or fix invalid geometries in the early stages of conversion.

Usually the problematic geometries had self-intersections and duplicate points, but some were stranger and had e.g. those inverted rings I mentioned before.

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



--
Alvaro Zabala Ordóñez
azabala[en]gmail[punto]com
alvaro.zabala[en]juntadeandalucia[punto]es
Tlf: 954 995 572
Gabinete de Normalización y Calidad
Servicio de Coordinación y Desarrollo de Sistemas Horizontales.
D.G. de Innovación y Administraciones Públicas.
Consejería de Innovación, Ciencia y Empresa, Junta de Andalucía



_______________________________________________
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: PolygonRectifier?

Larry Becker
I think you are mixing up rendering systems (Java2D) with topology packages.  These have different goals and different data requirements.

Larry Becker

On Thu, Feb 12, 2009 at 7:04 AM, Alvaro Zabala <[hidden email]> wrote:
The problem is that OpenJUMP uses JTS as geometry model, and JTS is a restrictive geometry model, based in SFS OGC specification.
This specification says "polygons shells must not have self-intersections", so when JTS finds this kind of geometry launchs an exception (TopologyException).

Other projects, like gvSIG, Geotools, etc. use a less restrictive geometry model: Java2D, for rendering geometries. So when the persistence driver reads a self-intersecting polygon shell, it doesnt create a JTS polygon, it creates a Java2D GeneralPath, geometry model which allows self-intersecting polygons.

In my opinion, one of the points where JTS could improve in this subject is not to "short-cuit" validation in isValid() geometry method. This method, when find an error, launchs an exception, so you need many iterations to correct a geometry at all.

I have developed a Quality Assurance library for gvSIG project: libTopology [1], to ensure topological correctness with a rule based model. Im planning to port this library to GeoAPI (in medium term, not before the final of 2009 for overworking :(  ), to allow geometry validations. I have desglosed all isValid validations in multiple steps [2]. This, of course, is only a proof of concepts.

[1] libTopology. http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/
[2] Decompsing isValid(). http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/src/org/gvsig/topology/topologyrules/JtsValidRule.java
2009/2/12 Tuure Laurinolli <[hidden email]>

Sunburned Surveyor wrote:
Tuure,

You wrote: "...OpenJUMP doesn't deal with some oddly broken geometries..."

What are you trying to do with these geometries and how are they broken?

With OpenJUMP I was trying to see if the invalid geometries were important enough to be salvaged, or if I could just drop them. This was part of preprocessing to get a Shape reader to accept them for conversion into a proprietary format. The converter read even the invalid geometries in fine, but at later stages of conversion there were problems - thus I had to find and either drop or fix invalid geometries in the early stages of conversion.

Usually the problematic geometries had self-intersections and duplicate points, but some were stranger and had e.g. those inverted rings I mentioned before.

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



--
Alvaro Zabala Ordóñez
azabala[en]gmail[punto]com
alvaro.zabala[en]juntadeandalucia[punto]es
Tlf: 954 995 572
Gabinete de Normalización y Calidad
Servicio de Coordinación y Desarrollo de Sistemas Horizontales.
D.G. de Innovación y Administraciones Públicas.
Consejería de Innovación, Ciencia y Empresa, Junta de Andalucía



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




--
http://amusingprogrammer.blogspot.com/

_______________________________________________
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: PolygonRectifier?

Martin Davis
In reply to this post by azabala
This is not totally correct.  JTS does not check topology when
geometries are created.  In fact, it deliberately avoids doing any
topology checks unless the user specifically requests them.  Some
operations necessarily expect a certain level of topology to exist (e.g.
the overlay ops and spatial predicates assume OGC SFS topology, whereas
distance doesn't require much at all).

This was done deliberately to allow systems to input and hold geometry
which could be invalid, in order to allow it to be cleaned by further
processing.

The isValid() predicate does not throw an exception, it returns a
boolean indicating an error in topological validity.  It was meant as a
simple pass/fail check, and was not intended to be a full topology error
analysis tool.  It is possible to get a text description of the
particular failure.  It would be possible to extend the IsValid class to
support returning multiple errors (and locations) when they can be
detected.  In my experience it's not possible to determine *all* errors
in a single pass, since some kinds of errors "mask" others (i.e. are so
egregious that they prevent further error detection being performed, or
cause them to be misinterpreted).

Alvaro Zabala wrote:

> The problem is that OpenJUMP uses JTS as geometry model, and JTS is a
> restrictive geometry model, based in SFS OGC specification.
> This specification says "polygons shells must not have
> self-intersections", so when JTS finds this kind of geometry launchs
> an exception (TopologyException).
>
> Other projects, like gvSIG, Geotools, etc. use a less restrictive
> geometry model: Java2D, for rendering geometries. So when the
> persistence driver reads a self-intersecting polygon shell, it doesnt
> create a JTS polygon, it creates a Java2D GeneralPath, geometry model
> which allows self-intersecting polygons.
>
> In my opinion, one of the points where JTS could improve in this
> subject is not to "short-cuit" validation in isValid() geometry
> method. This method, when find an error, launchs an exception, so you
> need many iterations to correct a geometry at all.
>
> I have developed a Quality Assurance library for gvSIG project:
> libTopology [1], to ensure topological correctness with a rule based
> model. Im planning to port this library to GeoAPI (in medium term, not
> before the final of 2009 for overworking :(  ), to allow geometry
> validations. I have desglosed all isValid validations in multiple
> steps [2]. This, of course, is only a proof of concepts.
>
> [1] libTopology.
> http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/
> [2] Decompsing isValid().
> http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/src/org/gvsig/topology/topologyrules/JtsValidRule.java
> 2009/2/12 Tuure Laurinolli <[hidden email]
> <mailto:[hidden email]>>
>
>     Sunburned Surveyor wrote:
>
>         Tuure,
>
>         You wrote: "...OpenJUMP doesn't deal with some oddly broken
>         geometries..."
>
>         What are you trying to do with these geometries and how are
>         they broken?
>
>
>     With OpenJUMP I was trying to see if the invalid geometries were
>     important enough to be salvaged, or if I could just drop them.
>     This was part of preprocessing to get a Shape reader to accept
>     them for conversion into a proprietary format. The converter read
>     even the invalid geometries in fine, but at later stages of
>     conversion there were problems - thus I had to find and either
>     drop or fix invalid geometries in the early stages of conversion.
>
>     Usually the problematic geometries had self-intersections and
>     duplicate points, but some were stranger and had e.g. those
>     inverted rings I mentioned before.
>
>     _______________________________________________
>     jts-devel mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://lists.refractions.net/mailman/listinfo/jts-devel
>
>
>
>
> --
> Alvaro Zabala Ordóñez
> azabala[en]gmail[punto]com
> alvaro.zabala[en]juntadeandalucia[punto]es
> Tlf: 954 995 572
> Gabinete de Normalización y Calidad
> Servicio de Coordinación y Desarrollo de Sistemas Horizontales.
> D.G. de Innovación y Administraciones Públicas.
> Consejería de Innovación, Ciencia y Empresa, Junta de Andalucía
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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: PolygonRectifier?

Aron Olsen
In reply to this post by azabala

Hi there,

 

If anyone is in need of it:

 

Attached you will find a SpatialOp-like class, that converts ESRI-holes to SFS-holes.

Please do whatever with it as you like. Currently it is in Java 5 coding style.

 

/Aron.

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Alvaro Zabala
Sent: 12 February 2009 14:04
To: JTS Topology Suite Development
Subject: Re: [jts-devel] PolygonRectifier?

 

The problem is that OpenJUMP uses JTS as geometry model, and JTS is a restrictive geometry model, based in SFS OGC specification.
This specification says "polygons shells must not have self-intersections", so when JTS finds this kind of geometry launchs an exception (TopologyException).

Other projects, like gvSIG, Geotools, etc. use a less restrictive geometry model: Java2D, for rendering geometries. So when the persistence driver reads a self-intersecting polygon shell, it doesnt create a JTS polygon, it creates a Java2D GeneralPath, geometry model which allows self-intersecting polygons.

In my opinion, one of the points where JTS could improve in this subject is not to "short-cuit" validation in isValid() geometry method. This method, when find an error, launchs an exception, so you need many iterations to correct a geometry at all.

I have developed a Quality Assurance library for gvSIG project: libTopology [1], to ensure topological correctness with a rule based model. Im planning to port this library to GeoAPI (in medium term, not before the final of 2009 for overworking :(  ), to allow geometry validations. I have desglosed all isValid validations in multiple steps [2]. This, of course, is only a proof of concepts.

[1] libTopology. http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/
[2] Decompsing isValid(). http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/src/org/gvsig/topology/topologyrules/JtsValidRule.java

2009/2/12 Tuure Laurinolli <[hidden email]>

Sunburned Surveyor wrote:

Tuure,

You wrote: "...OpenJUMP doesn't deal with some oddly broken geometries..."

What are you trying to do with these geometries and how are they broken?

 

With OpenJUMP I was trying to see if the invalid geometries were important enough to be salvaged, or if I could just drop them. This was part of preprocessing to get a Shape reader to accept them for conversion into a proprietary format. The converter read even the invalid geometries in fine, but at later stages of conversion there were problems - thus I had to find and either drop or fix invalid geometries in the early stages of conversion.

Usually the problematic geometries had self-intersections and duplicate points, but some were stranger and had e.g. those inverted rings I mentioned before.


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




--
Alvaro Zabala Ordóñez
azabala[en]gmail[punto]com
alvaro.zabala[en]juntadeandalucia[punto]es
Tlf: 954 995 572
Gabinete de Normalización y Calidad
Servicio de Coordinación y Desarrollo de Sistemas Horizontales.
D.G. de Innovación y Administraciones Públicas.
Consejería de Innovación, Ciencia y Empresa, Junta de Andalucía


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

EsriToSfsOp.java (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PolygonRectifier?

Larry Becker
Aron,
 
I'm looking at the following comment in your code. I understand the concept of boundary-defined rings, but I'm a little confused by "adds them as interior LinearRings to other interior rings present in that Polygon."

 *  In ArcSDE polygon-holes touching an exterior/interior boundary in a single point is formed
 *  by a self-closing "loop" in that exterior/interior boundary. This is not SFS/JTS-valid.

 *  This converter removes such boundary-defined "rings" from the outer and interior rings of
 *  a JTS Polygon, and adds them as interior LinearRings to other interior rings present
 *  in that Polygon.

This sounds like an important special case, but I've never encountered it.  Can you give an example to make it clearer?

best regards,
Larry Becker

On Fri, Feb 13, 2009 at 3:14 AM, Aron Olsen <[hidden email]> wrote:

Hi there,

 

If anyone is in need of it:

 

Attached you will find a SpatialOp-like class, that converts ESRI-holes to SFS-holes.

Please do whatever with it as you like. Currently it is in Java 5 coding style.

 

/Aron.

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Alvaro Zabala
Sent: 12 February 2009 14:04
To: JTS Topology Suite Development
Subject: Re: [jts-devel] PolygonRectifier?

 

The problem is that OpenJUMP uses JTS as geometry model, and JTS is a restrictive geometry model, based in SFS OGC specification.
This specification says "polygons shells must not have self-intersections", so when JTS finds this kind of geometry launchs an exception (TopologyException).

Other projects, like gvSIG, Geotools, etc. use a less restrictive geometry model: Java2D, for rendering geometries. So when the persistence driver reads a self-intersecting polygon shell, it doesnt create a JTS polygon, it creates a Java2D GeneralPath, geometry model which allows self-intersecting polygons.

In my opinion, one of the points where JTS could improve in this subject is not to "short-cuit" validation in isValid() geometry method. This method, when find an error, launchs an exception, so you need many iterations to correct a geometry at all.

I have developed a Quality Assurance library for gvSIG project: libTopology [1], to ensure topological correctness with a rule based model. Im planning to port this library to GeoAPI (in medium term, not before the final of 2009 for overworking :(  ), to allow geometry validations. I have desglosed all isValid validations in multiple steps [2]. This, of course, is only a proof of concepts.

[1] libTopology. http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/
[2] Decompsing isValid(). http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/src/org/gvsig/topology/topologyrules/JtsValidRule.java

2009/2/12 Tuure Laurinolli <[hidden email]>

Sunburned Surveyor wrote:

Tuure,

You wrote: "...OpenJUMP doesn't deal with some oddly broken geometries..."

What are you trying to do with these geometries and how are they broken?

 

With OpenJUMP I was trying to see if the invalid geometries were important enough to be salvaged, or if I could just drop them. This was part of preprocessing to get a Shape reader to accept them for conversion into a proprietary format. The converter read even the invalid geometries in fine, but at later stages of conversion there were problems - thus I had to find and either drop or fix invalid geometries in the early stages of conversion.

Usually the problematic geometries had self-intersections and duplicate points, but some were stranger and had e.g. those inverted rings I mentioned before.


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




--
Alvaro Zabala Ordóñez
azabala[en]gmail[punto]com
alvaro.zabala[en]juntadeandalucia[punto]es
Tlf: 954 995 572
Gabinete de Normalización y Calidad
Servicio de Coordinación y Desarrollo de Sistemas Horizontales.
D.G. de Innovación y Administraciones Públicas.
Consejería de Innovación, Ciencia y Empresa, Junta de Andalucía


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




--
http://amusingprogrammer.blogspot.com/

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