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

[Obe, Regina]

Mark,

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

My thoughts exactly - I'm thinking of this as at best a stop-gap and
also as to an expectation of how well a GEOS solution should perform -
in my mind GEOS should outperform any PostgreSQL only solution I come up
with and if it doesn't something is very fishy.  

I think Martin had said GEOS is on average (or was it someone else)
about 2 to 3 times slower than JTS for these kinds of things it mimicks
which doesn't seem quite right to me why that would be the case.  So am
I right in saying is that the assumption that I am already 1/3 the speed
of JTS in many cases - the general consensus is with the current state
of code even with cascade implemented line per line as it is in JTS - we
shouldn't expect any better than that.  or am I wrong?

Well since Java does have automatic garbage cleanup and C/C++ don't or
at least much less so it takes much longer to get a solution right in
C++ than it would in say Java or even in PostgreSQL functions.  But then
I think prototyping in PostgreSQL would give a better sense of the
expectation of a GEOS solution than necessarily comparing it to JTS
directly.  Would a finely optimized solution in GEOS perform better than
it does in JTS - maybe - but certainly it should perform better than any
PostgreSQL only solution since I know there is a a boundary penalty I am
paying for dividing the geometries into smaller arrays to feed to GEOS.

Thanks,
Regina
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.