[postgis-users] ST_3DIntersection slow/hanging with moderately complex shapes

[Rubio Vaughan]

Thank you for the explanation Hugo. That's quite a dramatic speedup!
The validity tag for a geometry sounds like a very good idea. There 
could be other functions which would benefit from this as well.

One of my colleagues, Tom van Tilburg, will be at the Paris code sprint. 
I'll ask him to buy you a beer for me.

One more thing: I noticed the postgres process seems to be hanging while 
performing the 3D intersection. Only a 'kill -9' would terminate the 
process. Is this normal for CGAL routines or is there a way to check for 
signals periodically and abort gracefully?

Best regards
Rubio Vaughan


On 2016-02-08 21:22, Hugo Mercier wrote:
> Hi Rubio,
>
> On 08/02/2016 18:38, Rubio Vaughan wrote:
>> Hi all,
>>
>> I've noticed that ST_3DIntersection becomes quite slow when feeding it
>> somewhat complex shapes.
>>
>> SELECT PostGIS_Full_Version() returns:
>> "POSTGIS="2.2.1 r14555" GEOS="3.5.0-CAPI-1.9.0 r4084" SFCGAL="1.2.2"
>> PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 2.0.1, released 2015/09/15"
>> LIBXML="2.9.1" LIBJSON="0.11.99" TOPOLOGY (topology procs from "2.1.4
>> r12966" need upgrade) RASTER (sfcgal procs from "2.2.0 r14208" need
>> upgrade)"
>>
>> The query below takes a polygon with 97 vertices and extrudes it
>> vertically by 5 meters. It then performs an ST_3DIntersection with a
>> simple rectangle, which is also extruded by 5 meters. This takes about
>> 15-20 seconds to run on our system, during which the postgres process
>> appears to hang until the query completes. The query can not be
>> cancelled or terminated, only a kill -9 will end the process.
>>
>> The polygon in the query below is an extract of a larger polygon with
>> 2451 vertices. Trying to perform the same query with the large polygon
>> results in a hanging postgres process.
>>
>> I would think that the 3D intersection is a relatively simple operation
>> which shouldn't be taking so long, but perhaps I'm expecting too much?
>>
> CGAL expects valid geometries in input. If it receives invalid
> geometries, there is no guarantee and bad things may happen (including
> session crashs).
> So the current situation is to check the validity of each input geometry
> before doing anything. This operation is complex (especially in 3D) and
> takes time.
>
> The only way to bypass this validity check for now is to recompile
> SFCGAL with SFCGAL_CHECK_VALIDITY set to "OFF".
>
> Executing your request on my machine, with validity check (the default):
> ~ 15 s
> Without validity check: ~ 0.13 s
>
> This issue will be discussed during the next code sprint in Paris.
>
> I think we need to add a way for the user to disable these checks
> without recompilation and maybe a way to tag or change the type of a
> geometry to mark it as valid ...
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users