discussione: http://osgeo-org.1560.x6.nabble.com/QGIS-master-e-SpatiaLite-5-td5458079.html

utmzones_area.geojson

query utilizzata:

UPDATE utmzones_area
 SET (area_spatialite_5_true,area_spatialite_5_false) = 
(
	select st_area(geom, true) as area_spatialite_5_true,
 	       st_area(geom, false) as area_spatialite_5_false
 	from utmzones_area t
 	where t.pk = utmzones_area.pk
)

OSGeo4W64 WIN 10

version

SELECT 
sqlite_version() as sqlite_version,
spatialite_version() as spatialite_version,
proj_version() as proj_version,
geos_version() as geos_version,
rttopo_version() as rttopo_version,
libxml2_version() as libxml2_version,
spatialite_target_cpu() as spatialite_target_cpu

---

🔗 https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html

In some screenshots the geometry field is "geom", in the failing case "geometry". Are you sure that you are using the correct name?

In some screenshots the geometry field is "geom", in the failing case "geometry". Are you sure that you are using the correct name?

QGIS sees the name of the geometry field in the case of a virtual layer,geom in the case of a sqlite table

virtual layer

sqlite

refs qgis/QGIS#41890

Trying following with plain spatialite to verify it's not an qgis issue:

SELECT load_extension('mod_spatialite');
SELECT InitSpatialMetadata(1);
SELECT 
sqlite_version() as sqlite_version,
spatialite_version() as spatialite_version,
proj_version() as proj_version,
geos_version() as geos_version,
rttopo_version() as rttopo_version,
libxml2_version() as libxml2_version,
spatialite_target_cpu() as spatialite_target_cpu;
SELECT ImportGeoJSON('utmzones_area.geojson', 'utmzones_area', 'geom', 1, 4326);
UPDATE utmzones_area
 SET (area_spatialite_5_true,area_spatialite_5_false) =
(
        select st_area(geom, true) as area_spatialite_5_true,
               st_area(geom, false) as area_spatialite_5_false
        from utmzones_area t
        where t.pk = utmzones_area.pk
);

On osgeo4w testing:

D:\TEMP\osgeo4w-2>set SPATIALITE_SECURITY=relaxed
D:\TEMP\osgeo4w-2>sqlite3 <check.sql

1
3.35.2|5.0.1|Rel. 8.0.0, March 1st, 2021|3.9.1-CAPI-1.14.2|1.1.0-dev|2.9.10|Windows_64bit
1204
RTTOPO error: ptarray_area_spheroid: cannot handle ptarray that crosses equator

[62x in total]

And on debian unstable (older sqlite3, older PROJ, slightly different RTTOPO):

$ SPATIALITE_SECURITY=relaxed sqlite3 <check.sql

1
3.34.1|5.0.1|Rel. 7.2.1, January 1st, 2021|3.9.0-CAPI-1.16.2|1.1.0|2.9.10|x86_64-linux-gnu
1204
RTTOPO error: ptarray_area_spheroid: cannot handle ptarray that crosses equator

[62x in total]

so it could be an upstream issue - in rttopo maybe?

interesting - what does 3.9.1-CAPI-1.14.2 vs 3.9.0-CAPI-1.16.2 mean?