[postgis-devel] Making SFCGAL mandatory

[Regina Obe]

On Thu, Nov 15, 2018 at 8:20 AM Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:


> -----Original Message-----
> From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org <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 <mailto: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 <mailto: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.

 

Agreed. 

 

Yes, this would have be an interesting approach back when we had the option, but sort of assumes using specific install schemas as a general policy, which not everyone does.

Since I was complaining about it being a basically unused features, I was this morning wondering about removing the run-time backend switch?  If we want to keep binding to specific CGAL functions that overlap GEOS functionality, then just naming them appropriately (CGAL_Intersects()? ST_IntersectsCGAL()?) would hardly be the end of the world.

 

P.

 

 

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

 

> Darafei Praliaskouski

 

 

Here is my second thought after reading both Paul and Darafei.

I don't want to check ST_IsSolid, want to keep it as a user preference because sometimes as the case in buildings, I don't want to treat my building as solid for intersects checks when Iam doing basic surveying.

I only care about surface intersects check and prefer the much faster speed of PostGIS native ST_3DIntersects over the more accurate SFCGAL one.

 

How about we just overload ST_Intesects, ST_3DIntersects and so forth.  We love overloading :)

 

And then get rid of the backend.

 

So anyone who wants to use the cgal version would do

 

ST_Intersects(geom1,geom2, 'cgal')

 

And geos would be the default.

 

We only need to do this for:

ST_3DDistance, ST_3DIntersects, ST_Intersects, ST_Area, ST_Distance

 

And I doubt few people really want to use cgal for the non-3D variants

So the ST_Intersects, ST_Area, ST_Distance are not serious breaking changes

 

Greg is probably screaming now at my horrid attempt at bottom posting.

 

Thanks,

Regina

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181116/0bd1e545/attachment.html>