[postgis-users] Simplifying a multipolygon layer, keeping polygon connection

[Nicolas Ribot]

On 11 April 2012 10:15, Sandro Santilli <strk at keybit.net> wrote:
> On Wed, Apr 11, 2012 at 10:01:12AM +0200, Nicolas Ribot wrote:
>> On 10 April 2012 12:04, Sandro Santilli <strk at keybit.net> wrote:
>> > On Mon, Apr 09, 2012 at 07:33:41PM +0200, Nicolas Ribot wrote:
>> >> Hmm much easier with Postgis Topology...
>> >>
>> >> (thanks Brent for the Topology example)
>> >>
>> >> By the way, is it the right way to use topology to simplify a layer ?
>> >
>> > It's one way, there may be multiple ones.
>> > Add this new way to to wiki ?
>>
>> Done: http://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyWithTopologyExt
>
> Great, thanks.
>
>> > It'd be interesting to see some banchmarks of the two methods you reported.
>>
>> Just som rough figures from my test:
>> Using first method, with a plpgsql function and spatial operators:
>>     • it takes ~ 7.5 second to process 96 multipolygons containing ~
>> 47000 vertices.
>>     • it takes ~ 9 minutes to process the 36610 communes
>> (=municipalities), containing more than 512000 vertices
>>
>> With Topology:
>>    • treating departements took 10.2 seconds on average.
>>    • I canceled the CreateTopoGeo after about 25 minutes.
>
> What you mean by "treating departments" ? Is that the 96 multipolygons
> with ~47000 vertices ?
>
> Can you do the comparison using the same (small) input for both ?
>

Yes, here are some stats:

Mac OS X Snow Leopard, SSD drive, 8 gb ram
shared_buffers = 5120MB
work_mem = 1024MB

POSTGIS="2.0.0 r9605" GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.7.1, 23
September 2009" GDAL="GDAL 1.8.0, released 2011/01/12" LIBXML="2.7.8"
TOPOLOGY RASTER

Number of objects in departement layer: 96 Num points  47036,

1°) Using spatial functions:
First run: 8953.493 ms, second run: 8808.133 ms

2°) Using Topology
First run: 13743 ms, second run: 14028 ms

(server stopped and restarted between runs.

> I'm interested in speeding up the case using topology.
>
> Note that ST_CreateTopoGeo needs to do all in memory which would be
> inappropriate for large datasets, the toTopoGeom function (and the
> underlying TopoGeo_addGeometry functions) would instead allow you to
> populate a topology incrementally.

I will test this function and let you know.

>
> For sure I can tell you that topology isn't meant to be used as a
> "temporary" storage. I can imagine, for example, that you want multiple
> resolutions of your data. You could build the topology once and then
> generate multiple simplified versions of it, or even simplify on demand
> with an ST_Simplify(TopoGeometry) [ to be implemented ].
>

Nicolas