[postgis-devel] Making SFCGAL mandatory
Regina Obe
lr at pcorp.us
Wed Nov 28 07:28:55 PST 2018
> 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.
More information about the postgis-devel
mailing list