ST_Snap doesn't maintain the input type

[lkajan]

I have encountered unexpected behavior when using the ST_Snap() function. According to my expectation, when passing a geometry to ST_Snap(), the result should be of the same type as the input. However, I've noticed that z-values are sometimes dropped, and multi-geometries are reduced to single geometries.

SELECT ST_AsText(ST_Snap('pointz(0.01 0 0)', 'point(0 0)', 0.1))
—POINT(0 0)

SELECT ST_AsText(ST_Snap('pointz(0.01 0 0)', 'pointz(0 0 nan)', 0.1))
—POINT(0 0)

SELECT ST_AsText(ST_Snap('multipoint((0.01 0))', 'point(0 0)', 0.1))
—POINT(0 0)

This behavior makes using results of ST_Snap less straightforward. For example, the following queries may not work as expected without ST_Multi and ST_Force3D functions:
UPDATE table1 SET geom = ST_Snap(geom, collection, 0.01) FROM …;
SELECT ST_Collect(ST_Snap(geom, collection), 0.01) FROM …; (ST_Collect excepts uniform dimensions)

Versions:

• PostgreSQL 16.0 (Debian 16.0-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
• POSTGIS="3.4.0 0874ea3" [EXTENSION] PGSQL="160" GEOS="3.9.0-CAPI-1.16.2" PROJ="7.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=​https://cdn.proj.org USER_WRITABLE_DIRECTORY=/var/lib/postgresql/.local/share/proj DATABASE_PATH=/usr/share/proj/proj.db" LIBXML="2.9.10" LIBJSON="0.15" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY

[robe]

I don't think ST_Snap was designed to work with z coordinates and on tok of that in some of your examples you are mixing dimensions. Regardless most of the logic of ST_Snap resides in GEOS so wouldn't be fixed in PostGIS.

@pramsey I'm going to close this out as a won't fix. Feel free to do something about it if you want.