Transformation between EPSG: 32632 and EPSG:32633 - problems with area values

[Antonio Valanzano]

I have downloaded a shapefile from ISTAT website with the
administrative boundaries of italian municipalities (Com01012026_WGS84
with EPSG:32632).

When I calculate the total area for my county (cod_reg = 17) I find a
difference between the value of the area calculated with the original
coordinates and that calculated with the coordinates transformed from
EPSG 32632 to EPSG 32633.

Here is my sql script with the results

SELECT
SUM("shape_area")/1000000 as sum_shape_area_column_kmq,
SUM(ST_Area("geometry"))/1000000 as sum_area_geometry_32632_kmq,
SUM(ST_Area(ST_Transform(geometry,32633)) / 1000000)as
sum_area_geometry_32633_kmq
FROM "Com01012026_WGS84"
WHERE cod_reg = 17;
-- 1 row
10073.185398 10073.185398 9986.345686

there is a difference of about 87 kmq.

Could someone explain to me why there is this difference if I have
only changed from time zone 32 to time zone 33 within the same datum
WGS84?
The geometries should not have been changed apart from a different
shift in the origin of the x coordinates.

Thanks in advance
Antonio

[a.fu...@lqt.it]

Il 2026-04-02 15:38 Antonio Valanzano ha scritto:
> there is a difference of about 87 kmq.
>
> Could someone explain to me why there is this difference if I have
> only changed from time zone 32 to time zone 33 within the same datum
> WGS84?
> The geometries should not have been changed apart from a different
> shift in the origin of the x coordinates.
>

Hi Antonio,

The problem is simply a consequence of floating-point arithmetic.
This type of numeric representation is practically universal because
it allows calculations to be performed extremely quickly, but it's
far from perfect because it suffers from truncation and rounding
errors.
There's nothing you can do about it, it's intrinsic to the design:
it's a small price to pay for efficiency and speed.

The difference you notice is really microscopic, less than 1 part
in 1000, and represents nothing more than the cumulative effect
of many tiny roundings or truncations.

A coordinate transformation involves a lot of floating-point
calculations, and on top of that you are calculating the sum
of an aggregate.
In total, you're unleashing a veritable blizzard of floating
point operations, and each of them is inexorably subject to
some imperceptible approximation.
the final result is affected by all these microscopic
inaccuracies, it cannot be otherwise.

Final conclusion: floating-point notation is also called
scientific notation because it performs calculations
following the usual criteria of physicists and engineers,
where a certain level of approximation and uncertainty
is always present.
From a practical point of view, an error of less than 1%
is essentially irrelevant and not significant, also because
the reliability of the upstream measurements is likely even
worse than this.
Let's leave absolute precision calculations to theoretical
mathematicians, Platonic philosophers, and accountants.
Scientists and engineers are accustomed to dealing with an
imperfect material world where small margins of approximation
are always inevitable.

bye Sandro

[Antonio Valanzano]

Sandro,

thanks for the answer and thanks also  for the advice of looking at the problem of approximations in calculations  with floating-point  numbers from a pragmatic point of view as  engineers should do..

Antonio 

[andrea antonello]

Hi Sandro,

your answer is interesting. Due to the same datum of the two crs I would have not thought of an ellipsoid jump or floating point issue, but more to the fact that the Italian shape is large enough to cross the two areas and being the crs not equal-area projections, some differences should occur?

I wonder if one or the other could be quantified?

Cheers,

Andrea

--
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialite-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/spatialite-users/CANV1FQbB5WZ_ej2XRRDWSC6OxmHc7cJo4vDJJsTEsTZtnx-Lyw%40mail.gmail.com.

[a.fu...@lqt.it]

Il 2026-04-03 09:22 andrea antonello ha scritto:
> Hi Sandro,
> your answer is interesting. Due to the same datum of the two crs I
> would have not thought of an ellipsoid jump or floating point issue,
> but more to the fact that the Italian shape is large enough to cross
> the two areas and being the crs not equal-area projections, some
> differences should occur?
>

Hi Andrea,

I think you're spot on.
The problem Antonio reported was related to his region, Basilicata,
which
is located in the eastern haòd of UTM zone 33, well outside the boundary
of zone 32.
It is therefore quite evident that the transformation of coordinates
between the two zones will inevitably be affected by distortions,
especially on the horizontal axis.
Distortions that certainly have a higher impact than those due to
floating-point truncations and roundings.

> I wonder if one or the other could be quantified?
>

I would expect the difference in area calculations to increase
from west to east:

- Umbria and Lazio are expected to show very limited discrepancies,
because they are located in the westernmost part of UTM zone 33.

- the worst deformations should affect Puglia, which even has
a small part of itself that falls within the UTM 34 zone.

- The smallest discrepancy of all is expected to be seen in
Emilia-Romagna, as it mostly falls in UTM zone 32 and only
Romagna is in UTM zone 33.

Eventually the analysis could also be conducted at lower levels
(Provinces, Municipalities) and in the end it should be possible
to measure (at least approximately) the contribution of the
deformations introduced by coordinate transformation.

bye Sandro

[Deyan Vasilev]

UTM like most of the projected CRS-es tend to "lose" accuracy towards the 6 degrees band edges, so polygons will have their areas expanded near the zone boundaries, compared to the zone centre.

If your particular polygon of interest is lying at the centre of the UTM 32N zone and you reproject your data to e.g. UTM 33N, you'll get quite different area calculations for the same polygon. This is not just because you lose some precision due to the FP arithmetic involved, but because your polygon is laying far away from the centre of the UTM 33N zone, even beyond its boundaries.

Best regards,

Deyan

--
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialite-use...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/spatialite-users/b725c30702fcbbb8ba2bf9535e2fb3f5%40lqt.it.

[Even Rouault]

Hi,

This has nothing to do with floating point accuracy, but very much with
the nature of the underlying projection method. EPSG:32632 and
EPSG:32633 both use the (Universal) Transverse Mercator projection,
which is a conformal projection, that is the vale of an angle between 2
vectors on the ellipsoid is preserved when transferred on the projected
surface. A consequence of that nice property is that it thus cannot be
equal area preserving... Cf
https://en.wikipedia.org/wiki/Transverse_Mercator_projection
. Furthermore there's a scale factor of 0.9996 applied for the UTM kind
of Transverse Mercator, so even for shapes close to the central meridian
of those projections, the area computed in cartesian projected
coordinates will be a bit smaller (0.9996 ^ 2 = 0.08 %) than the area on
the ellipsoid.

Conclusion: use ST_Area(geometry_column, TRUE) to get an accurate
surface value.

Even

--
http://www.spatialys.com
My software is free, but my time generally not.

[a.fu...@lqt.it]

Il 2026-04-03 11:30 Deyan Vasilev ha scritto:
> UTM like most of the projected CRS-es tend to "lose" accuracy towards
> the 6 degrees band edges, so polygons will have their areas expanded
> near the zone boundaries, compared to the zone centre.
>
> If your particular polygon of interest is lying at the centre of the
> UTM 32N zone and you reproject your data to e.g. UTM 33N, you'll get
> quite different area calculations for the same polygon. This is not
> just because you lose some precision due to the FP arithmetic
> involved, but because your polygon is laying far away from the centre
> of the UTM 33N zone, even beyond its boundaries.
>

Hi Deyan,

That's exactly right.
The Italian peninsula is large enough from west to east to completely
cover two UTM zones (32 and 33), with a small portion of Puglia (the
"heel of the boot") even falling into UTM zone 34.
The central meridian of UTM zone 32 passes through Sardinia near
Cagliari, while that of UTM zone 33 passes through Campania near
Naples.

Strictly speaking, only in this very narrow zone are UTM coordinates
rigorously precise; in the rest of the national territory they are
always affected by a certain degree of approximation.
However, these deformations are practically imperceptible as long
as one remains within +/- 3 degrees from the central meridian of
the UTM zone, while they will increase more and more as the angular
distance grows.
But will remain reasonably small within an angular distance of
+/- 9 degrees from the central meridian, small enough to be
virtually irrelevant for normal geographic/cartographic
applications where extreme accuracy is not required.
In other words, as long as you stay within three contiguous UTM
zones, it makes sense to use the central UTM zone to produce
national-scale maps.
And this is exactly what Italian public bodies do as a general
rule.

Certainly, precision losses due to floating-point arithmetic
also contribute, but to a much lesser extent.

bye Sandro

[a.fu...@lqt.it]

Il 2026-04-03 13:14 Even Rouault ha scritto:
> Conclusion: use ST_Area(geometry_column, TRUE) to get an accurate
> surface value.
>

This is a really brilliant tip to get around all the problems associated
with
calculating areas on projected maps.
Unfortunately, however, this is not entirely correct; precise area
calculation
is only possible for geometries with geographic coordinates (lat/long),
otherwise
you'll only get NULL results... and unfortunately the ISTAT dataset is
only
available in UTM zone 32 (32632).

However, we can start from this idea of ​​yours to arrive at a more
precise
measurement of the rounding and approximation effects.

SELECT AddGeometryColumn('com_istat', 'utm33', 32633, 'MultiPolygon',
'XY');
UPDATE com_istat SET utm33 = ST_Transform(geometry, 32633);
SELECT AddGeometryColumn('com_istat', 'wgs84', 4326, 'MultiPolygon',
'XY');
UPDATE com_istat SET wgs84 = ST_Transform(geometry, 4326);

We now have _three_ geometries for each Italian municipality: one
in UTM32, the other in UTM33, and the last in WGS84 (lat/long).
At this point we are going to create a temporary table to simplify
all subsequent processing.

CREATE TEMPORARY TABLE tmp_com AS
SELECT a.cod_reg, b.den_reg, b.shape_area / 1000000.0 AS km2_istat,
Sum(ST_Area(a.geometry)) / 1000000.0 AS km2_utm32,
Sum(ST_Area(a.utm33)) / 1000000.0 AS km2_utm33,
Sum(ST_Area(a.wgs84, 1)) / 1000000.0 AS km2_wgs84
FROM com_istat AS a
JOIN reg01012026_wgs84 AS b ON (a.cod_reg = b.cod_reg)
GROUP BY b.cod_reg;

SELECT cod_reg, den_reg, km2_istat,
km2_wgs84, km2_istat - km2_wgs84 AS delta_wgs84,
((km2_istat - km2_wgs84) / km2_istat) * 1000.0 AS pp1000
FROM tmp_com
ORDER BY Abs(pp1000);

This query allows us to calculate the deviations (delta_wgs84)
between the areas pre-calculated by ISTAT (km2_istat) and those
calculated precisely on the ellipsoid (km2_wgs84).
pp1000 expresses the deviations measured in parts per thousand.

cod_reg den_reg km2_istat, km2_wgs84 delte pp1000
===============================================================
8 Emilia-Romagna 22501.812507 22502.360540 -0.548032 -0.024355
2 Valle d'Aosta/Vallée
d'Aoste 3260.842686 3262.229805 -1.387119 -0.425387
5 Veneto 18355.235547 18346.877457 8.358090 0.455352
9 Toscana 22989.803182 23001.511283 -11.708102 -0.509274
3 Lombardia 23863.088101 23879.663973 -16.575872 -0.694624
20 Sardegna 24108.538923 24127.219345 -18.680422 -0.774847
1 Piemonte 25386.727822 25409.160789 -22.432967 -0.883649
10 Umbria 8464.202686 8453.978601 10.224085 1.207921
7 Liguria 5417.622796 5424.316400 -6.693604 -1.235524
12 Lazio 17239.366235 17211.739254 27.626982 1.602552
6 Friuli-Venezia Giulia 7933.295957 7920.509615 12.786342 1.611731
11 Marche 9346.018846 9328.998834 17.020012 1.821098
4 Trentino-Alto
Adige/Südtirol 13604.704803 13636.064846 -31.360043 -2.305088
13 Abruzzo 10831.715370 10797.363923 34.351447 3.171376
19 Sicilia 25835.308181 25930.360374 -95.052193 -3.679158
14 Molise 4460.562761 4440.700726 19.862035 4.452809
15 Campania 13675.723739 13609.395288 66.328451 4.850087
16 Puglia 19542.704452 19421.180192 121.524260 6.218395
17 Basilicata 10073.185398 9992.880163 80.305235 7.972179
18 Calabria 15219.297663 15084.790192 134.507471 8.837955

As we can see, all regions show some deviations, for the reasons
that Even has excellently explained.
And as we expected, the imperfections become more and more noticeable
going from west to east and moving away from the central meridian
of the UTM32 zone.
But there's one more interesting thing to note: these are, in any
ase, reasonable approximations of a few thousandths, acceptable
for many purposes.

very last step.

SELECT cod_reg, den_reg, km2_istat, km2_utm32,
km2_istat - km2_utm32 AS delta_utm32
FROM tmp_com;

This last query compares the regional area values ​​pre-calculated by
ISTAT with those calculated by ST_Area on the UTM 32 zone (planar).

cod_reg den_reg km2_istat km2_utm32 delta_umt32
=========================================================
1 Piemonte 25386.727822 25386.727822 -1.408989e-08
2 Valle d'Aosta/Vallée d'Aoste 3260.842686 3260.842686 -3.830337e-09
3 Lombardia 23863.088101 23863.088101 -1.921217e-08
4 Trentino-Alto Adige/Südtirol 13604.704803 13604.704803 -3.208697e-09
5 Veneto 18355.235547 18355.235547 -2.498200e-08
6 Friuli-Venezia Giulia 7933.295957 7933.295957 4.753019e-09
7 Liguria 5417.622796 5417.622796 4.206413e-09
8 Emilia-Romagna 22501.812507 22501.812507 -1.953958e-08
9 Toscana 22989.803182 22989.803182 3.995228e-08
10 Umbria 8464.202686 8464.202686 -3.961759e-09
11 Marche 9346.018846 9346.018846 7.275958e-12
12 Lazio 17239.366235 17239.366235 1.511944e-08
13 Abruzzo 10831.715370 10831.715370 -1.650005e-08
14 Molise 4460.562761 4460.562761 -2.679371e-09
15 Campania 13675.723739 13675.723739 -3.937203e-08
16 Puglia 19542.704452 19542.704452 2.940942e-08
17 Basilicata 10073.185398 10073.185398 6.308255e-09
18 Calabria 15219.297663 15219.297663 -4.676622e-08
19 Sicilia 25835.308181 25835.308181 -4.383764e-09
20 Sardegna 24108.538923 24108.538923 -3.599780e-08

We continue to have discrepancies, but this time they are truly
infinitesimal, less than 1 part per million.
These are the discrepancies attributable to different roundings
(different software, different hardware).

We are now able to answer Andrea's question about the relative
contribution of approximation errors due to coordinate
transformation and floating-point arithmetic roundings.

- both effects exist, but they have very different impacts.

- Unavoidable approximations with planar projections typically
count for 1 part in a thousand discrepamciea.

- Rounding errors in floating-point arithmetic are much smaller,
typically less than parts per million.

bye Sandro

[andrea antonello]

Huuuuu, standing ovation. Fantastic thread :-)

--
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialite-use...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/spatialite-users/0a380a04511f434232bb20e3cadb8a61%40lqt.it.

[Deyan Vasilev]

Sandro,

I really love the way you illustrated the whole point, thanks!

Deyan

To view this discussion visit https://groups.google.com/d/msgid/spatialite-users/CACck5jOVwXUoczXjpoamof8mmT%2BN-7AiyoE224e%2BBYfL%3D6%3Dc1A%40mail.gmail.com.