[postgis-devel] Making SFCGAL mandatory

[Nicklas Avén]

On Wed, 2018-11-28 at 12:26 +0100, Hugo Mercier wrote:
> 
> 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 ...


There is also a pitfall when people use the SFCGal 2d distance functions without knowing it.
 They are quite a lot slower than the PostGIS native distance functions.

/Nicklas




> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel