[postgis-devel] Making SFCGAL mandatory

[Regina Obe]

> 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.
> 
[Regina Obe] 
I like that idea.  ST_3DIntersection I wasn't so concerned with because PostGIS core doesn't have that at all,
Though I like the semantic difference between the two.

Maybe we can mark ST_3DIntersection as deprecated

> 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 ?
> 
[Regina Obe] 
That's what I thought the difference was too and I would say probably not.
I can't think of a reason why people want to manage 2D TIN / 2D polyhedralsurfaces just cause they exist.

> There is also a SFCGAL ST_Area(), but I can't remember what it adds ...
[Regina Obe] 
I haven't tried, maybe it works for TINs where as the PostGIS one definitely doesn't.