[postgis-devel] Making SFCGAL mandatory
Nicklas Avén
nicklas.aven at jordogskog.no
Wed Nov 28 03:29:44 PST 2018
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
More information about the postgis-devel
mailing list