[PROJ] question about EPSG:3003

[a.furieri at lqt.it]

I notice an unpleasant regression in the proj-string returned by
proj_as_proj_string() for EPSG:3003 Monte Mario / Italy zone 1
in all previous versions, accordingly to the string returned by
calling the GDAL function OSRExportToProj4(), this was defined
as follows:

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 \
+ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \
+units=m +no_defs

but in PROJ.6 the string returned by calling proj_as_proj_string()
is now:

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 \
+ellps=intl +units=m +no_defs +type=crs

as you can notice, the +towgs84 member has been suppressed,
and the sad practical consequence is that any transformation
based on the above proj-string (as e.g. from EPSG:4326 to
EPSG:3003) is now shifted by about 75 metres (at least, this
is true on Tuscany).

if I remember well after so many years, PROJ.4/GDAL initially
supported a definition for 3003 lacking the +towgs84 member,
and this caused endless troubles to all italian users.
but since 2012 (more or less) PROJ.4/GDAL started supporting
a revised proj-string including the +towgs84 member, and it
was an highly appreciated improvement.
now PROJ.6 seems to mark a bad regression to the dark past.

note: this is not at all an issue for new SpatiaLite versions
fully based on PROJ.6, because in this case ST_Transform()
will use by default the CRS definitions retrieved from the
PROJ.6 own SQLite database.
but nevertheless a very dangerous scenario exists.
imagine some SpatiaLite database created by a recent
version based on PROJ.6
in this case the "spatial_ref_sys" table will be
populated by inserting the proj-strings returned
by proj_as_proj_string().
if such a database will be connected in a second
time to some earlier version of SpatiaLite still
based on old PROJ.4 (a not at all uncommon practice
in the  peculiar world of spatialite) any call to
ST_Transform() will then be based on the proj-strings
stored into "spatial_ref_sys", and any transformation
to/from srid=3003 will be inexorably affected by
severe shifts.

any idea/comment/suggestion about this ?

bye Sandro

p.s. the same identical issue affects srids
3004, 23032 and 23033