[Fwd: Re: UnionOP for huge polygon collection]

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Fwd: Re: UnionOP for huge polygon collection]

Martin Davis

Markus,

Thanks for the test data.  I ran this with no problems in JTS, in about
2.7 sec on my machine.  (See the attached image)

One thing I noticed about the code you provide is the line in
UnionWithUnionOp:

    return allinOnePolygon.getCoordinates();

This will not give you useful results if the allinOnePolygon geometry is
a MultiPolygon and/or has holes.  getCoordinates() concatenates all
coordinate sequences together, which when display will have an
appearance which I think looks like what you're seeing.  I think you
need more checks for the actual polygon structure in that routine.
Really you're better off returning the actual geometry created, not the
list of vertices in it.

Martin



Markus Eichhorn wrote:

> Hi Martin,
> I already got an workaround. With a combination of
> CascadedPolygonUnion and the Polygonizer I found a workaround.
> But this is more slowly than it could be.
> Appending a test shape.
>
> In short, the following code is the on giving me the incorrect result,
> which looks like the picture (the picture is from another test case,
> but explains what I suppose).
>
> ...
> DataStore dataStore = DataStoreFinder.getDataStore(connectParameters);
> // getting the shape
>
> FeatureSource<SimpleFeatureType, SimpleFeature> featureSource;
> FeatureCollection<SimpleFeatureType, SimpleFeature> collection;
> FeatureIterator<SimpleFeature> iterator;
>
> featureSource = dataStore.getFeatureSource(typeName);
> collection = featureSource.getFeatures();
> iterator = collection.features();
>
> ArrayList<Geometry> allPolygons= new ArrayList<Geometry>();  
> Geometry onePoly;
> while (iterator.hasNext()) {
>                         SimpleFeature feature = iterator.next();
>                         onePoly= (Geometry) feature.getDefaultGeometry();
>                         allPolygons.add(onePoly);
> }
>
> return UnionWithUnionOp(allPolygons);
> }
>
> With
> private Coordinate[] UnionWithUnionOp(ArrayList<Geometry> allPolygons){
>              Geometry allinOnePolygon = UnaryUnionOp.union(allPolygons);
>        return allinOnePolygon.getCoordinates();
>    }
>
> So, you needn't to go into it. I can work with myworkaround. But if
> you want to, you're welcome!
> Greets & Thanks
> Markus
>    
>
> 2009/9/15 Martin Davis <[hidden email]
> <mailto:[hidden email]>>
>
>     Markus,
>
>     Your approach is exactly right - that's what UnaryUnionOp is
>     designed to do.  I'm not sure why you're seeing incorrect results
>     - the output seems very strange. If you can post some test data or
>     even better a simple test case I can dig into this to see what's
>     going on.
>
>     Another post suggested noding first. This is not necessary,
>     UnaryUnionOp does any noding required.
>
>     Martin
>
>     Markus Eichhorn wrote:
>
>         Hi list,
>         I've been trying to union a collection of Geometry-object (all
>         elements are polygons). But with the
>         geometry.union(other);  it is much to slow for huge collection.
>         So I used the UnaryUnionOp (see code).
>
>         private Coordinate[] UnionWithUnionOp(ArrayList<Geometry>
>         allPolygons){
>                      Geometry allinOnePolygon =
>         UnaryUnionOp.union(allPolygons);
>                return allinOnePolygon.getCoordinates();
>            }
>
>         After union the polygons with the UnaryUnionOp the order of
>         coordinates of the result polygon is not right ( I think,
>         because of the polygons are not ordered and distributed all
>         over the space). So I get an self overlapping polygon which
>         makes lots of problems for the visualisation.
>         Is my handling of the UnaryUnionOp false? Or can't I handle
>         such spread polygons with it?
>         Thanks for answers or hints!
>         Greets
>         Markus
>         ------------------------------------------------------------------------
>
>         _______________________________________________
>         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
>
>
>
> ------------------------------------------------------------------------
>
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022




--
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

geoms.png (65K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: UnionOP for huge polygon collection]

Martin Davis
And if you really just want the coordinates of the outer shell of the
polygon, and are willing to ignore any multipolygon output, you could use:

return ( (Polygon) allinOnePolygon.getGeometryN(0)
).getExteriorRing().getCoordinates();

Martin Davis wrote:

>
> Markus,
>
> Thanks for the test data.  I ran this with no problems in JTS, in
> about 2.7 sec on my machine.  (See the attached image)
>
> One thing I noticed about the code you provide is the line in
> UnionWithUnionOp:
>
>    return allinOnePolygon.getCoordinates();
>
> This will not give you useful results if the allinOnePolygon geometry
> is a MultiPolygon and/or has holes.  getCoordinates() concatenates all
> coordinate sequences together, which when display will have an
> appearance which I think looks like what you're seeing.  I think you
> need more checks for the actual polygon structure in that routine.
> Really you're better off returning the actual geometry created, not
> the list of vertices in it.
>
> Martin
>
>
>
> Markus Eichhorn wrote:
>> Hi Martin,
>> I already got an workaround. With a combination of
>> CascadedPolygonUnion and the Polygonizer I found a workaround.
>> But this is more slowly than it could be.
>> Appending a test shape.
>>
>> In short, the following code is the on giving me the incorrect
>> result, which looks like the picture (the picture is from another
>> test case, but explains what I suppose).
>>
>> ...
>> DataStore dataStore =
>> DataStoreFinder.getDataStore(connectParameters); // getting the shape
>>
>> FeatureSource<SimpleFeatureType, SimpleFeature> featureSource;
>> FeatureCollection<SimpleFeatureType, SimpleFeature> collection;
>> FeatureIterator<SimpleFeature> iterator;
>>
>> featureSource = dataStore.getFeatureSource(typeName);
>> collection = featureSource.getFeatures();
>> iterator = collection.features();
>>
>> ArrayList<Geometry> allPolygons= new ArrayList<Geometry>();  
>> Geometry onePoly;
>> while (iterator.hasNext()) {
>>                         SimpleFeature feature = iterator.next();
>>                         onePoly= (Geometry)
>> feature.getDefaultGeometry();
>>                         allPolygons.add(onePoly);
>> }
>>
>> return UnionWithUnionOp(allPolygons);
>> }
>>
>> With
>> private Coordinate[] UnionWithUnionOp(ArrayList<Geometry> allPolygons){
>>              Geometry allinOnePolygon = UnaryUnionOp.union(allPolygons);
>>        return allinOnePolygon.getCoordinates();
>>    }
>>
>> So, you needn't to go into it. I can work with myworkaround. But if
>> you want to, you're welcome!
>> Greets & Thanks
>> Markus
>>  
>> 2009/9/15 Martin Davis <[hidden email]
>> <mailto:[hidden email]>>
>>
>>     Markus,
>>
>>     Your approach is exactly right - that's what UnaryUnionOp is
>>     designed to do.  I'm not sure why you're seeing incorrect results
>>     - the output seems very strange. If you can post some test data or
>>     even better a simple test case I can dig into this to see what's
>>     going on.
>>
>>     Another post suggested noding first. This is not necessary,
>>     UnaryUnionOp does any noding required.
>>
>>     Martin
>>
>>     Markus Eichhorn wrote:
>>
>>         Hi list,
>>         I've been trying to union a collection of Geometry-object (all
>>         elements are polygons). But with the
>>         geometry.union(other);  it is much to slow for huge collection.
>>         So I used the UnaryUnionOp (see code).
>>
>>         private Coordinate[] UnionWithUnionOp(ArrayList<Geometry>
>>         allPolygons){
>>                      Geometry allinOnePolygon =
>>         UnaryUnionOp.union(allPolygons);
>>                return allinOnePolygon.getCoordinates();
>>            }
>>
>>         After union the polygons with the UnaryUnionOp the order of
>>         coordinates of the result polygon is not right ( I think,
>>         because of the polygons are not ordered and distributed all
>>         over the space). So I get an self overlapping polygon which
>>         makes lots of problems for the visualisation.
>>         Is my handling of the UnaryUnionOp false? Or can't I handle
>>         such spread polygons with it?
>>         Thanks for answers or hints!
>>         Greets
>>         Markus
>>        
>> ------------------------------------------------------------------------
>>
>>         _______________________________________________
>>         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
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>
>
> ------------------------------------------------------------------------
>

--
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