Opened 18 months ago
Last modified 3 months ago
#5405 closed enhancement
Reexpose SFCGAL ST_3DIntersects and ST_3DDistance perhaps as SC_3DIntersects, SC_3DDistance — at Initial Version
Reported by: | robe | Owned by: | robe |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 3.5.0 |
Component: | sfcgal | Version: | master |
Keywords: | Cc: |
Description
There were several functions we got rid of when we removed the backend GUC in postgis. These were functions that had the same name in both PostGIS proper and SFCGAL, but hte SFCGAL variant would take oever when you did
set postgis.backend=sfcgal
From the 3.0 credits here is what we have
ST_3DDistance - Changed: 3.0.0 - SFCGAL version removed Returns the 3D cartesian minimum distance (based on spatial ref) between two geometries in projected units. ST_3DIntersects - Changed: 3.0.0 SFCGAL backend removed, GEOS backend supports TINs. Returns TRUE if the Geometries "spatially intersect" in 3D - only for points, linestrings, polygons, polyhedral surface (area). ST_Intersection - Changed: 3.0.0 does not depend on SFCGAL. (T)Returns a geometry that represents the shared portion of geomA and geomB. ST_Intersects - Changed: 3.0.0 SFCGAL version removed. Returns TRUE if the Geometries/Geography "spatially intersect in 2D" - (share any portion of space) and FALSE if they don't (they are Disjoint). For geography tolerance is 0.00001 meters (so any points that close are considered to intersect)
I don't think there is a need to reexpose ST_Intersection and ST_Intersects as I think that was mostly to handle 2D TINS which don't have a solid counterpart.
I think ST_3DDistance and ST_3DIntersects that SFCGAL provided are still useful for true surfaces that are solids.
I don't think we settled on a prefix for these. I was thinking SC or SG or CG.