[postgis-devel] Making SFCGAL mandatory

[Darafei "Komяpa" Praliaskouski]

I created a ticket for this all and copied relevant parts of discussion
there:
https://trac.osgeo.org/postgis/ticket/4258

On Wed, Nov 28, 2018 at 2:30 PM Nicklas Avén <nicklas.aven at jordogskog.no>
wrote:

>
>
> 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel



-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181128/6c5c850c/attachment-0001.html>