[postgis-devel] Making SFCGAL mandatory

[Darafei "Komяpa" Praliaskouski]

On Thu, Nov 22, 2018 at 10:57 PM Regina Obe <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?



>
>
> *From:* postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] *On
> Behalf Of *Darafei "Kom?pa" Praliaskouski
> *Sent:* Sunday, November 18, 2018 7:25 AM
> *To:* PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> *Subject:* Re: [postgis-devel] Making SFCGAL mandatory
>
>
>
>
>
> сб, 17 нояб. 2018 г. в 11:23, Regina Obe <lr at pcorp.us>:
>
> >  How about we just overload ST_Intesects, ST_3DIntersects and so forth.
> We love overloading ☺
> >  And then get rid of the backend.
>
> >  So anyone who wants to use the cgal version would do
>
> > ST_Intersects(geom1,geom2, 'cgal')
>
> Disregard my proposed solution here of overloading the functions.  I just
> realized that wouldn't solve the ultimate gripe I had of SFCGAL being part
> of the postgis lib.
> It would only give more granular control of when to use SFCGAL/PostGIS
> overlapping functions than Backend GUC does.
>
>
>
> What if we treat it all just like GEOS version test?
>
> i.e. there is always a function from SFCGAL, and if PostGIS is compiled
> without it it just says "please recompile", and if there is we're lucky and
> it just works.
>
> Regarding solid and non-solid intersection - what if they are indeed two
> distinct operations, just like ST_Contains and ST_Intersects that mean
> basically the same thing for point-and-polygon, but start differing with
> higher dimensions? Maybe we can find two different words for solid
> intersection and non-solid intersection operations, and then one of them
> will be GEOS and another CGAL?
>
>
>
-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181125/b2e2454d/attachment.html>