ST_3DMaxDistance curved geometries mixed dimension yields DIST_MAX mode not supported

[robe]

Running thru garden tests, and just noticed this. I'm not sure if this is bug or not, but message is very confusing.

-- in PostGIS 2.2 r13966

SELECT ST_3DMaxDistance('GEOMETRYCOLLECTION Z (MULTIPOLYGON Z (((-71.0821 42.3036 2,-71.0822 42.3036 2,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2))),POLYGON Z ((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 1,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1)))'::geometry, 'MULTISURFACE(CURVEPOLYGON(CIRCULARSTRING(-71.0821 42.3036,-71.4821 42.3036,-71.7821 42.7036,-71.0821 42.7036,-71.0821 42.3036),(-71.1821 42.4036,-71.3821 42.6036,-71.3821 42.4036,-71.1821 42.4036)))'::geometry);

returns error:

NOTICE:  One or both of the geometries is missing z-value. The unknown z-value will be regarded as "any value"


ERROR:  lw_dist2d_ptarray_ptarrayarc does not currently support DIST_MAX mode
********** Error **********

ERROR: lw_dist2d_ptarray_ptarrayarc does not currently support DIST_MAX mode
SQL state: XX000

In PostGIS 2.1.8 it returns:

ERROR:  Unsupported geometry type: CircularString
********** Error **********

ERROR: Unsupported geometry type: CircularString
SQL state: XX000

Now I'm unclear do we support curves in 3D now with the 3D functions?

-- for this query

SELECT ST_3DDistance('GEOMETRYCOLLECTION Z (MULTIPOLYGON Z (((-71.0821 42.3036 2,-71.0822 42.3036 2,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2))),POLYGON Z ((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 1,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1)))'::geometry, 'MULTISURFACE(CURVEPOLYGON(CIRCULARSTRING(-71.0821 42.3036,-71.4821 42.3036,-71.7821 42.7036,-71.0821 42.7036,-71.0821 42.3036),(-71.1821 42.4036,-71.3821 42.6036,-71.3821 42.4036,-71.1821 42.4036)))'::geometry);

PostGIS 2.2 returns 0.

In PostGIS 2.1.8, I get

ERROR:  Unsupported geometry type: CircularString
********** Error **********

[nicklas]

I don't have a fresh trunk to test on here.

The error you see comes from 2D calculation, not 3D since z-value is missing.

In the version I have here Maxdistance isn't supported in 2D either for circular string. Is that the same in latest trunk?

If we are not going to support maxdistance with circular string in 2d or 3d I just have to catch that earlier in this special case when mixing 3D and 2D calls. In some way we now get past the check by jumping from 3D to 2D.

[robe]

nicklas,

I was testing with:

POSTGIS="2.2.0dev r13966" GEOS="3.5.0-CAPI-1.9.0 r4088" PROJ="Rel. 4.9.1, 04 March 2015" GDAL="GDAL 2.0.0, released 2015/06/14" LIBXML="2.7.8" LIBJSON="0.12" RASTER

When I run with ST_MaxDistance, it appears to be supported (whether it gives right answer is another question)

SELECT ST_MaxDistance('GEOMETRYCOLLECTION Z (MULTIPOLYGON Z (((-71.0821 42.3036 2,-71.0822 42.3036 2,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2))),POLYGON Z ((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 1,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1)))'::geometry, 'MULTISURFACE(CURVEPOLYGON(CIRCULARSTRING(-71.0821 42.3036,-71.4821 42.3036,-71.7821 42.7036,-71.0821 42.7036,-71.0821 42.3036),(-71.1821 42.4036,-71.3821 42.6036,-71.3821 42.4036,-71.1821 42.4036)))'::geometry);

--outputs
0.806349831028689

[nicklas]

Ok, thanks

I will try to take a look this evening. I have :

POSTGIS="2.2.0dev r13114" GEOS="3.5.0dev-CAPI-1.9.0 r4026" PROJ="Rel. 4.9.0, 27 October 2013" GDAL="GDAL 1.11dev, released 2013/04/13" LIBXML="2.8.0" LIBJSON="0.11.99" RASTER

and the error message I get from the query below is quite strange(but apparently outdated):

select st_MaxDistance('point(1 1)'::geometry, 'circularstring(1 1, 2 2, 2 1)'::geometry);

It says:

ERROR:  Exception in LWGEOM2GEOS: curved geometry not supported.

Why it is tried converted to GEOS format is more than I understand.

[nicklas]

ST_MaxDistance actually supports curves. But the function isn't aware of that. If works becasue all geoemtries to ST_MaxDistance goaes through ST_ConvexHull and then curves becomes polygons.

But 3D is another story because ST_Convexhull would take away nessecary information for 3Dcalculations since ST_ConvexHull isn't 3D aware.

Anyway. The fix in this case is to catch curves in the mixed dimentionality case before sending to 2D calc. This is done in r13970

Or actually i only let Points, Lines and Polygons get through.

It doesn't affect cases with 2 3D geoemtries but only when at least 1 of the geometries only have 2 dims.

Otherwise those curves will be cached later in the process. But collections of different kinds with mixed dimmentionality is also affected. Because they are not evaluted yet when I do the check. Maybe have to redo that thing :-( What do you think Is it important that collections in the mixed dimmentionality case is let through?

[robe]

nicklas see #3256, I suspect something you changed in r13970 is causing this new crash I am seeing.

[robe]

nevermind. I have to figure out why sfcgal is kicking in. I didn't install the extension in this database.

[robe]

okay closing this one out.