Oh yep, that’s a positively ancient GEOS (Google cloud?) you really need to get a newer one under your PostGIS, or you’ll have all sorts of failures in your overlays, etc, that have long since been fixed. GEOS 3.13 is API backwards compatible with 3.8 so there’s really no reason not to go with the latest.
P. > On Apr 3, 2025, at 2:49 PM, Denis Rykov <ryk...@gmail.com> wrote: > > Thanks for the quick response, Paul! > > $ select postgis_full_version(); > > POSTGIS="3.5.2 dea6d0a" [EXTENSION] PGSQL="120" GEOS="3.8.0-CAPI-1.13.1 " > PROJ="6.3.1" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" > WAGYU="0.5.0 (I > nternal)" > (1 row) > > On Thu, Apr 3, 2025 at 11:45 PM Paul Ramsey <pram...@cleverelephant.ca > <mailto:pram...@cleverelephant.ca>> wrote: >> “Works for me”, what’s your version collection? >> >> pramsey=# select postgis_full_version(); >> >> POSTGIS="3.6.0dev 3.5.0-228-g2c8f40113" [EXTENSION] PGSQL="170" >> GEOS="3.14.0dev-CAPI-1.20.0" PROJ="9.3.0 NETWORK_ENABLED=ON >> URL_ENDPOINT=https://cdn.proj.org <https://cdn.proj.org/> >> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj >> DATABASE_PATH=/usr/local/share/proj/proj.db" (compiled against PROJ 9.3.0) >> GDAL="GDAL 3.9.3, released 2024/12/10 (debug build)" LIBXML="2.9.13" >> LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" (core procs from >> "3.6.0dev 3.5.0-186-g2845d3f37" need upgrade) RASTER (raster lib from "3.5.0 >> 3.5.0-211-g202d59f44" need upgrade) (raster procs from "3.5.0 3.5.0" need >> upgrade) >> >> >>> On Apr 3, 2025, at 2:43 PM, Denis Rykov <ryk...@gmail.com >>> <mailto:ryk...@gmail.com>> wrote: >>> >>> Is it expected for ST_ClipByBox2D to return NaN coordinates for 'POLYGON Z' >>> geometries? >>> >>> Here is an example. The following SQL query: >>> >>> SELECT >>> ST_AsText( >>> ST_SimplifyPreserveTopology( >>> ST_ClipByBox2D( >>> ST_GeomFromText( >>> 'POLYGON Z ((9109727.260586184 7235765.611871982 >>> 0,9109793.397475857 7235780.37911723 0,9109880.551536862 7235799.226171476 >>> 0,9109912.974452058 7235743.263961895 0,9109949.41754929 7235677.287550647 >>> 0,9109986.927785816 7235610.625640362 0,9110029.388466287 7235535.445041807 >>> 0,9110063.152192863 7235481.075809712 0,9110058.528985653 7235478.79780619 >>> 0,9110066.094453445 7235463.4091950925 0,9110094.816342745 >>> 7235418.349932027 0,9110128.716586944 7235357.442269537 0,9110170.311475156 >>> 7235283.992565744 0,9110207.570403146 7235217.92016041 0,9110271.536255063 >>> 7235090.866183731 0,9110290.55592083 7235042.889807568 0,9110192.389007365 >>> 7235014.391634338 0,9110169.194172846 7235007.739006326 0,9109951.366830455 >>> 7235432.506918687 0,9109937.453975307 7235459.0955318 0,9109797.566462943 >>> 7235663.435298668 0,9109727.260586184 7235765.611871982 0))' >>> ), >>> ST_MakeEnvelope( >>> 9108725.486174684, 7235101.049109253, >>> 9111416.069569945, 7237791.632504516 >>> ) >>> ), >>> 5 >>> ) >>> ); >>> >>> fails with the 'Geometry contains invalid coordinates' error, but wrapping >>> the geometry in ST_Force2D makes it work. >>
