Have ST_3DIntersects to recognize Triangle as a type

[smathermather]

The product from ST_3DIntersection with SFCGAL is a geometry collection of points, linestrings, as well TIN for the volumetric portion. It'd be mighty nice if ST_3DIntersects would test TINs too, instead of erroring out with "unrecognized type".

[vmo]

test=# set postgis.backend = sfcgal;
test=# select st_3Dintersects('TIN(((0 0,1 0,0 1,0 0)))'::geometry, 'POINT(.1 .1)'::geometry);
 st_3dintersects 
-----------------
 t
(1 row)
 
test=# set postgis.backend = geos;
test=# select st_3Dintersects('TIN(((0 0,1 0,0 1,0 0)))'::geometry, 'POINT(.1 .1)'::geometry);
ERROR:  Unsupported geometry type: Triangle
CONTEXT:  SQL function "st_3dintersects" statement 1

The latter seems to come from liblwgeom/measures3d.c

[robe]

I'm flagging this as a documentation bug since our ST_3DIntersects page: ​http://postgis.net/docs/manual-dev/ST_3DIntersects.html

doesn't tell you that ST_3DIntersects SFCGAL has it's own implementation which only takes into effect if the sfcgal backend is enabled.

[nicklas]

I think it should be quite easy to implement triangle support also in PostGIS native version. If I recall right I didn't just because I had some plan to make triangle handled in a more optimized way. But to just eat them as other polygons just taking care of that there is no extra point in the end shouldn't be difficult. Do we want that?

[robe]

I made a change to the doco at r13183

Check it out and see if it makes sense ​http://postgis.net/docs/manual-dev/ST_3DIntersects.html

One thing I am not sure about is how SFCGAL treats closed surfaces. As I recall I think it treats it as a solid and so ST_3DIntersects for closed polyhedral surfaces may return a different answer than what the built-in ST_3DIntersects returns. Also the documentation was a bit out-dated in that lwgeom only sT_3DIntersects does support polygons and polyhedral surfaces (I think this may have been a limitation in early 2.0, but got changed at release time thought it hasn't been very stress tested). I'll have to verify that before I backport.

[vmo]

robe: the closed polyhedral are not handled differently than polyhedral in sfcgal (or it should be filed as a bug).

To be treated as a solid, a closed polyhedral needs to have the solid flag set, which currently only happens for geometries coming from SFCGAL (e.g. result of extrusion).

I have a postgis patch for the next release of sfcgal that will provide functions to test/set the solid flag in postgis, I'll post it as soon as the new release of sfcgal is done.

[robe]

vmo,

Hmm I might have been testing by extruding a polygon then but to be honest, I was testing ST_3DIntersection. So are you saying that if you say ST_Extrude a rectangle so it becomes a solid polyhedral surface, then ST_3DIntersects would treat it as solid? even though the ST_AsText gives you a PolyhedralSurface indistinguishable from the one you built from text?

[vmo]

robe,

Yes, that's why I added an ST_IsSolid in the patch that I prepared for the support of SFCGAL 1.1.

[robe]

I was just wondering if we should have a Solid / MultiSolid type similar to what I think Oracle has ​http://docs.oracle.com/database/121/SPATL/sdo_intro.htm#SPATL468 Though that might be a major undertaking so probably best to table till 2.3

Regarding the ST_IsSolid patch where is that or are you still preparing it? Might as well also add an ST_SetSolid(geometry,boolean) if not too much trouble that allows you to set and unset that bit, but does validation to insure it is a closed surface and errors if it's not.

I think for people running versions of SFCGAL lower than 1.1, we can just return a NOT implemented message similar to what we do if someone calls a geojson function and they did not compile with JSON support.

[vmo]

The patch is still in preparation (because there is one thing too many in it ).

I will propose it in a separate ticket.

The ST_SetSolid is in there already there. It's a pure postgis function, so there is no need for the 'not implemented'. It does not check that the surface is closed, but the ST_IsValid from SFCGAL will tell you that the solid is invalid if the surface is open.

Concerning the Solid type: that would be great, but until the type is normalized it may not be the best thing to do. I don't konw.

[robe]

I think it's too late for this — will push to 2.3.0

[dbaston]

Assuming this is covered by the patch @vmo described above. If not, please re-open.