[postgis-devel] Ordering of geometries in multipolygons, preparedgeometries

[Mark Cave-Ayland]

Obe, Regina wrote:

> Mark,
> 
> FYI - I've been working on a PostgreSQL only solution to Cascaded Union
> and so far the results seem very promising.  To some it may seem counter
> intuitive instead of just porting the JTS code straight into GEOS.
> There are couple of reasons for me for going this somewhat round-about
> way.
> 
> 1) I'm scared of GEOS code at the moment.

Me too :)

> 2) It would be nice for people to reap benefits without having to
> upgrade to the latest GEOS.

Maybe. I think you've done a really good job in proving the case of 
implementing cascaded union within PostGIS, however ultimately it would 
make sense to write an implementation in C to make it as efficient as 
possible. But then if you have to spend the time writing it in C, you 
may as well upgrade to C++ and add it to GEOS so that other projects can 
benefit the work done.

It could be that we use one of your methods as a stop-gap until the code 
hits GEOS; I suspect that a lot of it depends of the relative release 
timeframes of PostGIS 1.4/GEOS 3.x...

> 3) I think there are a few memory leaks in GEOS and I really think we
> need to get that stabilized before we introduce new code into it.  This
> I think Paul Ramsey is working on.

I don't see that this is too much of a problem, since if any major 
changes are required within the GEOS tree, it can simply be branched 
before committing any changes to preserve the current level of 
reliability within the existing stable branch.

> 4) There is more of a cost I have observed between flipping into the
> GEOS layer from PostgreSQL which seems a bit more costly than the cost
> of flipping into lwpostgis code but still the flipping into lwpostgis
> code layer is not a free flip.  This is easily demonstrated by the speed
> differences between using ST_GeometryN and ST_Dump where ST_Dump only
> needs to make one call and ST_GeometryN needs to make many.  
>
> So I'm trying to minimize the cost of flipping so to speak - by doing
> things like sorting before it even gets passed to the GEOS layer.

Yeah. This is the age-old problem of the cost of conversion from PostGIS 
<>GEOS geometries, although I don't know whether sorting as LWGEOMs 
before conversion to GEOS would be any faster? From a performance point 
of view, it is clear that we should focus on caching for 
TOAST/LWGEOM/GEOSGEOM transformations on a per-query basis, although the 
exact detail is not yet known.

> 5) I'm not convinced a straight JTS to Geos port is the right thing to
> do. From listening to this group,  I think the techniques you use in
> each would be slightly different - just as if you were to do things in
> database land - the techniques you would use to solve the same problems
> optimally would be different than what you would do writing in C, C++ or
> Java.  This is giving me an opportunity to get a sense of how JTS is
> tackling things and if it really makes sense to make a 1 to 1
> translation to GEOS or if such a thing is even possible.

AIUI the problem with GEOS is not with the algorithms but with the 
memory management; I think the aim of doing this was to make porting 
future features from JTS to GEOS would be much easier, although sadly it 
is proving to be one of the major bottlenecks :(


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063