[postgis-devel] Making SFCGAL mandatory
Darafei "Komяpa" Praliaskouski
me at komzpa.net
Tue Feb 19 23:22:20 PST 2019
I implemented support for 3D solid POLYHEDRALSURFACE and 3D solid TIN on
Implementation of three dimensional ST_3DIntersection / ST_3DDistance I
believe is now feature-match with SFCGAL, so I removed SFCGAL switch
without any renamings.
This way I removed most of sfcgal tests, which are in turn are just core
tests with backend switch on top.
There are things in postgis_sfcgal that really all not about SFCGAL, like
ST_MakeSolid or ST_IsSolid - they can be moved out of it as they only check
Anybody willing to split up the .so files now that the math is fixed?
On Sat, Dec 1, 2018 at 1:59 PM Darafei "Komяpa" Praliaskouski <me at komzpa.net>
> I've started removing SFCGAL function clones.
> ST_Area is committed to trunk, ST_Distance is similarly going to be
> Overlay functions to follow. If you have any precious query example that
> does not work without SFCGAL, it's really time to get it into test suite
> (or at least this thread), before those get removed and "we never promised
> *that* will work". I've checked 2D TINs on ST_Area manually and it worked
> even on my 2.5. On the other hand, SFCGAL just barfs on CIRCULARSTRING, so
> removing SFCGAL there seems to *add* features.
> ср, 28 нояб. 2018 г. в 18:28, Regina Obe <lr at pcorp.us>:
>> > It looks fine to me as well.
>> > I also agree we better find a semantic difference between function
>> > 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
>> > 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.
>> [Regina Obe]
>> I like that idea. ST_3DIntersection I wasn't so concerned with because
>> PostGIS core doesn't have that at all,
>> Though I like the semantic difference between the two.
>> Maybe we can mark ST_3DIntersection as deprecated
>> > 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 ?
>> [Regina Obe]
>> That's what I thought the difference was too and I would say probably not.
>> I can't think of a reason why people want to manage 2D TIN / 2D
>> polyhedralsurfaces just cause they exist.
>> > There is also a SFCGAL ST_Area(), but I can't remember what it adds ...
>> [Regina Obe]
>> I haven't tried, maybe it works for TINs where as the PostGIS one
>> definitely doesn't.
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
> Darafei Praliaskouski
> Support me: http://patreon.com/komzpa
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the postgis-devel