[postgis-devel] Making SFCGAL mandatory

Fri Nov 16 06:05:55 PST 2018

So, this way another question arises: who is using SFCGAL backend overloads
and what are the use cases? What if we just drop SFCGAL overloads?

3D and StraightSkeleton-like SFCGAL-only features are understood.

Maybe we need to make a case inside ST_3DIntersects that will check
ST_IsSolid and choose to call SFCGAL/GEOS depending on what's usually
faster, instead of backend switch?

We have a similar case for Delaunay - it looks like SFCGAL can provide
Constrained Delaunay (a proper one that takes lines into account) but GEOS
is just much faster on points-only. What if it selected an appropriate
library depending on argument types?

On Thu, Nov 15, 2018 at 7:20 PM Regina Obe <lr at pcorp.us> wrote:

>
> > -----Original Message-----
> > From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On
> Behalf
> > Of Sandro Santilli
> > Sent: Thursday, November 15, 2018 5:25 AM
> > To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> > Subject: Re: [postgis-devel] Making SFCGAL mandatory
> >
> > On Thu, Nov 15, 2018 at 01:08:54PM +0300, Darafei "Kom?pa" Praliaskouski
> > wrote:
> >
> > > >
> > > > Probably. I don't remember exactly why we chose to use GUC.
> > > > Functions in their own schema like sfcgal.ST_Intersects() could have
> > > > been a solution as well (?)
> > >
> > > Can we change that for PostGIS 3.0, so that instead of
> > > postgis.backend=sfcgal one will set search_path=postgis_sfcgal,public?
> >
> > +1
> >
> > --strk;
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
> [Regina Obe]
> What?  NO  -1
>
> That is a super breaking change.  We'd have to remove the postgis schema
> qualfications in SFCGAL since we wouldn't know where postgis is installed.
> We've already got issues with postgis.topology and postgis_tiger_geocoder
> because of this.
> Let's not compound the issue.
>
> The reason we introduced the backend was because we had fantasies of
> SFCGAL functions overtaking GEOS.  That has not happened yet, and may never
> will.
>
> In reality the only functions that fall into this boat where the backend
> even comes into play outline in the pretty little chart here
>
>
> https://postgis.net/docs/manual-2.5/PostGIS_Special_Functions_Index.html#PostGIS_TypeFunctionMatrix
> - those ones with white cubes -- that's our overlap.
>
> Let's consider some of these:
>
> ST_Intersects -- I never understood why we'd want to use SFCGAL for this
> as the intersects in SFCGAL is much slower.  I think it was so the 3D
> behaves consistently so only useful if you want a 2D intersects for a 3D
> geometry or need a intersects for TINS (accept possibly for 2D TINS -- who
> on earth has 2D TINS?) - it's way slower.  With your proposed schema
> search_path craziness I'd be forced to schema qualify WHICH ST_Intersects I
> want anyway to prevent it from using the slower SFCGAL one I DON'T WANT or
> schema qualify all my SFCGAL function uses.
>
> ST_Union - again WHY - why would I want to use SFCGAL ST_Union for a 2D
> geometry (except for 2D TINS).
>
> ST_3DDistance -- okay yah I'd need this for solids -- you've got me there,
> but I still think we would have done better to call this ST_CGAL3DDistance
> or something.
>
> ST_3DIntersects - this is a good case where it really matters in a useful
> way.  I'd much prefer calling it a different name (as Paul suggested) cause
> they really aren't the same and I wouldn't be guessing which one I'm
> using,  , but has the benefit of being able to handle TINS and also doing
> true SOLID intersects check.  Ours is just surface test at best as it
> treats each polygon patch as if it were just a 3D polygon and I don't think
> handles TINS.
> Often times though I prefer using the built-in PostGIS one cause it's 100
> times faster (though it's less correct), so I'd still need to schema
> qualify which one to use, which makes the whole search_path idea NOT
> USEFUL.
>
> ST_3DIntersection which Paul mentioned -- only SFGCAL implements this so
> it's always SFCGAL being used in this case regardless what backend you
> set.  Sure GEOS may someday but that hasn't happened.
>
> What on earth makes you think that just because I'm using an SFCGAL
> function, I'd want to use the ST_Intersects/ST_3DIntersects of SFCGAL?
>
> e.g in case of ST_StraightSkeleton -- which is only implemented by SFCGAL,
> that's really useful for 2D geometries, but I always use the PostGIS
> ST_Intersects if I need it, and I DON'T want to have to go around schema
> qualifying my use just to get the right one.
>
>
> Thanks,
> Regina
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181116/f48bcc2b/attachment.html>