[postgis-devel] Making SFCGAL mandatory

[Darafei "Komяpa" Praliaskouski]

Hi,

I implemented support for 3D solid POLYHEDRALSURFACE and 3D solid TIN on
lwgeom side.
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
flags.

Anybody willing to split up the .so files now that the math is fixed?
https://trac.osgeo.org/postgis/ticket/4258

On Sat, Dec 1, 2018 at 1:59 PM Darafei "Komяpa" Praliaskouski <me at komzpa.net>
wrote:

> I've started removing SFCGAL function clones.
>
> ST_Area is committed to trunk, ST_Distance is similarly going to be
> https://github.com/postgis/postgis/pull/347/files
>
> 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
>> 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.
>> >
>> [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
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
> --
> Darafei Praliaskouski
> Support me: http://patreon.com/komzpa
>


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