CastToXYZ on empty geometry returns weird data with EnableGpkgMode()

46 views
Skip to first unread message

Pieter Roggemans

unread,
Dec 13, 2025, 5:00:33 AM12/13/25
to SpatiaLite Users
Hello Sandro,

In the beginning of 2024 I reported a crash when running some functions on an empty geometry in a GPKG file: https://groups.google.com/g/spatialite-users/c/nzwISNn0eO8/m/uh2rWEW3AAAJ

I'm not sure it this is the same, but I encountered a similar but possibly slightly different issue.

When running the following query in GDAL on an empty geometry the xmin returned is the max int value (1.7976931348623157e+308).
> SELECT ST_MinX(CastToXYZ(geom)) AS minx FROM "src_lyr"

However, when I run this query in plain SQLite + Spatialite this does return the expected NULL, so I'm not able to reproduce it "standalone".

The ~reason of this difference is that ST_MinX is implemented in GDAL as well..., so when I run this query using GDAL it is the GDAL version that takes precedence, and that version returns maxint.

I reported an issue in the GDAL issue tracker: https://github.com/OSGeo/gdal/issues/13557

Rouault looked into it, and apparently CastToXYZ returns odd data when ran on an empty geometry with EnableGpkgMode enabled. 

Quote from Rouault: "It returns a GeoPackage header that with the Empty bit set to 0 (so a non-empty geometry) and the ExtentXY bit set (whereas the minx,miny,maxx,maxy are set to +/- DBL_MAX)"

He implemented a workaround in GDAL to catch this case, but it would be a lot better if this would be fixed at the source.

In the following geopackage fid=47 is an empty geometry:

Here a script that gives some info, but doesn't reproduce the problem ;-).

> -- Init
> SELECT load_extension('mod_spatialite');
> SELECT EnableGpkgMode();
>
> SELECT GeomFromText('GeometryCollection()');
>
> SELECT * FROM "parcels";
> -- Returns 16 which is a bit weird, but it isn't 0 so OK enough for me.
> SELECT ST_IsEmpty(geom) FROM "parcels" WHERE fid = 47;
> SELECT ST_NPoints(geom) FROM "parcels" WHERE fid = 47;
> -- Returns "GEOMETRYCOLLECTION()"
> SELECT ST_AsText(geom) FROM "parcels" WHERE fid = 47;
> -- Returns NULL in when ran in SQLITE, but apparently the data returned by  CastToXYZ(geom)
> -- is pretty weird
> SELECT ST_MinX(CastToXYZ(geom)) FROM "parcels" WHERE fid = 47;
> -- I reported a crash on empty geometries in the beginning of 2024 which was fixed but hasn't
> -- been released yet... so this stil crashes.
> SELECT ST_ReducePrecision(geom, 0.001) FROM "parcels" WHERE fid = 47;

Regards,
Pieter

sandro furieri

unread,
Dec 22, 2025, 3:36:35 AM12/22/25
to spatiali...@googlegroups.com, Pieter Roggemans
Il 2025-12-13 11:00 Pieter Roggemans ha scritto:
> When running the following query in GDAL on an empty geometry the xmin
> returned is the max int value
>

Hi Pieter,

sorry for the late reply.

The problem arises from the fact that SpatiaLite does not provide
for empty geometries, assuming that they should correspond to NULL.

Unfortunately, there is a major bug in the GPKG reading module
which instead tries, in a rather fancy way, to create the equivalent
of an empty geometry when it encounters one.

The net result is simply that you end up with an invalid binary
geometry (BLOB), which will definitely cause problems and may
even trigger a crash.

The only possible way to represent an empty geometry in Spatialite
is to treat it as a NULL, anything else will surely cause infinite
trouble.

The next version that will be released will eliminate the problem
in the sense indicated above.

For now, the only possible solution is to filter the GPGC geometries
upstream by directly eliminating all empty geometries.

bye Sandro

Pieter Roggemans

unread,
Dec 23, 2025, 4:40:06 PM12/23/25
to SpatiaLite Users
That's good news.

I have been seeing very occasional (once every many hours for very long running processes) quite random crashes with queries using spatialite function on GPKG files. Hopefully they will be solved with this fix.

It would be great if the fix would be released... do you have any idea when this might be possible?

Regards,
Pieter

Op maandag 22 december 2025 om 09:36:35 UTC+1 schreef sandro furieri:
Reply all
Reply to author
Forward
0 new messages