[postgis-devel] Making SFCGAL mandatory

[Hugo Mercier]

On 25/11/2018 10:12, Darafei "Komяpa" Praliaskouski wrote:
> 
> 
> On Thu, Nov 22, 2018 at 10:57 PM Regina Obe <lr at pcorp.us
> <mailto:lr at pcorp.us>> wrote:
> 
>     Not following how that helps getting rid of SFCGAL from the postgis
>     library itself.  The GUC thing doesn't bother me that much and will
>     annoy me even less when 3.0 comes out since we will not have two
>     backends coexisting during upgrade for the life of PostGIS 3 major.____
> 
>     __ __
> 
>     It's the fact it's part of postgis library and not a separate
>     library like rtpostgis or postgis_topology that bugs me.____
> 
>     __ __
> 
>     Because for packaging you can never cleanly with one compile a
>     separate package for postgis_sfcgal that depends on postgis  and a
>     package for just postgis.____
> 
>     Your postgis package will always be infected with postgis_sfcgal if
>     it were ever to be used as a dependency in the postgis_sfcgal package.
> 
> 
> 1. we remove branching on postgis/sfcgal for same functions. They always
> go to postgis.
> 2. if SFCGAL func version adds some value or behavior change, we
> untangle them by names (not just adding _SFCGAL, but semantic
> difference) and put sfcgal version into postgis_sfcgal extension.
> 3. functions like ST_StraightSkeleton skeleton straight to
> postgis_sfcgal.so.
> 4. postgis.so has no linkage to sfcgal.
> 5. postgis_sfcgal.so may have linkage to whatever it needs.
> 6. if there is a difference in implementation (postgis knows no TIN,
> sfcgal knows no curve) that goes to each of untangled function's manual
> entry.
> 
> Does it look like a plan?
> 

It looks fine to me as well.

I also agree we better find a semantic difference between function
names, rather than just adding a "SFCGAL" prefix or suffix.

The main difference is that SFCGAL handles TIN/PolyhedralSurfaces and is
able to work with them either as meshes or as volumes (if the mesh is
closed).

So for functions that overlap and are handled by the backend switch that
we would like to avoid, what about something like ST_3DIntersection()
that becomes ST_3DMeshIntersection() + ST_3DVolumeIntersection() in
postgis_sfcgal.so ? With similar prefix "mesh" and "volume" for union,
difference, intersects.

About 2D intersection handled by SFCGAL, the only added value is the
handling of TIN/PS. But do we really need such things in 2D only ?

There is also a SFCGAL ST_Area(), but I can't remember what it adds ...