<div dir="ltr"><div>I created a ticket for this all and copied relevant parts of discussion there:</div><div dir="ltr"><a href="https://trac.osgeo.org/postgis/ticket/4258">https://trac.osgeo.org/postgis/ticket/4258</a><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 28, 2018 at 2:30 PM Nicklas Avén <<a href="mailto:nicklas.aven@jordogskog.no">nicklas.aven@jordogskog.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Wed, 2018-11-28 at 12:26 +0100, Hugo Mercier wrote:<br>
> <br>
> On 25/11/2018 10:12, Darafei "Komяpa" Praliaskouski wrote:<br>
> > <br>
> > <br>
> > On Thu, Nov 22, 2018 at 10:57 PM Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a><br>
> > <mailto:<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>>> wrote:<br>
> > <br>
> >     Not following how that helps getting rid of SFCGAL from the postgis<br>
> >     library itself.  The GUC thing doesn't bother me that much and will<br>
> >     annoy me even less when 3.0 comes out since we will not have two<br>
> >     backends coexisting during upgrade for the life of PostGIS 3 major.____<br>
> > <br>
> >     __ __<br>
> > <br>
> >     It's the fact it's part of postgis library and not a separate<br>
> >     library like rtpostgis or postgis_topology that bugs me.____<br>
> > <br>
> >     __ __<br>
> > <br>
> >     Because for packaging you can never cleanly with one compile a<br>
> >     separate package for postgis_sfcgal that depends on postgis  and a<br>
> >     package for just postgis.____<br>
> > <br>
> >     Your postgis package will always be infected with postgis_sfcgal if<br>
> >     it were ever to be used as a dependency in the postgis_sfcgal package.<br>
> > <br>
> > <br>
> > 1. we remove branching on postgis/sfcgal for same functions. They always<br>
> > go to postgis.<br>
> > 2. if SFCGAL func version adds some value or behavior change, we<br>
> > untangle them by names (not just adding _SFCGAL, but semantic<br>
> > difference) and put sfcgal version into postgis_sfcgal extension.<br>
> > 3. functions like ST_StraightSkeleton skeleton straight to<br>
> > postgis_sfcgal.so.<br>
> > 4. postgis.so has no linkage to sfcgal.<br>
> > 5. postgis_sfcgal.so may have linkage to whatever it needs.<br>
> > 6. if there is a difference in implementation (postgis knows no TIN,<br>
> > sfcgal knows no curve) that goes to each of untangled function's manual<br>
> > entry.<br>
> > <br>
> > Does it look like a plan?<br>
> > <br>
> <br>
> It looks fine to me as well.<br>
> <br>
> I also agree we better find a semantic difference between function<br>
> names, rather than just adding a "SFCGAL" prefix or suffix.<br>
> <br>
> The main difference is that SFCGAL handles TIN/PolyhedralSurfaces and is<br>
> able to work with them either as meshes or as volumes (if the mesh is<br>
> closed).<br>
> <br>
> So for functions that overlap and are handled by the backend switch that<br>
> we would like to avoid, what about something like ST_3DIntersection()<br>
> that becomes ST_3DMeshIntersection() + ST_3DVolumeIntersection() in<br>
> postgis_sfcgal.so ? With similar prefix "mesh" and "volume" for union,<br>
> difference, intersects.<br>
> <br>
> About 2D intersection handled by SFCGAL, the only added value is the<br>
> handling of TIN/PS. But do we really need such things in 2D only ?<br>
> <br>
> There is also a SFCGAL ST_Area(), but I can't remember what it adds ...<br>
<br>
<br>
There is also a pitfall when people use the SFCGal 2d distance functions without knowing it.<br>
 They are quite a lot slower than the PostGIS native distance functions.<br>
<br>
/Nicklas<br>
<br>
<br>
<br>
<br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div>Darafei Praliaskouski</div><div>Support me: <a href="http://patreon.com/komzpa" target="_blank">http://patreon.com/komzpa</a></div></div></div></div>