Monday 24 June 2013

An example of “local reprojection” from WGS84 to Gauss-Boaga Rome40 with SQLite/SpatiaLite

A common problem for many Italian GIS users in archaeology is to reproject vector features from WGS84 to Gauss-Boaga Rome40 (national Spatial Reference System in Italy till 2012). For shapefiles this transformation can be performed by specific GIS tools, often based on PROJ library (, by OGR utilities (i.e. ogr2ogr: or others standalone software.
In SQLite/SpatiaLite the reprojection between 2 different Spatial Reference Systems (SRS) is provided by “Transform” function (for complete description and syntax see: it’s possible to convert data in all the many Spatial Reference Systems stored in SpatiaLite’s “spatial_ref_sys” table and coded by SRID (Spatial Reference Identifier) and EPSG dataset. For example, to transform a vector from WGS84 to UTM ED50 it's enough to update geometry field in your table with the following SQL command:

UPDATE your_table SET geometry_field = Transform(geomWGS84, 23032);

where “geomWGS84” is a geometry field in WGS84 system (EPSG:4326) and “23032” is EPSG value for UTM ED50 zone 32 N.
The problem is that the reprojection between global systems often yields an approximate and imprecise result. For reaching a more accurate outcome a “local reprojection” is required: it is feasible using specific parameters of transformation (translation, rotation and scaling), different for each part of territory.
My example is about Veneto Region in Northern Italy. I needed to reproject some points, representing archaeological sites of this Region, from WGS84 to Gauss-Boaga Rome40 – West (EPSG:3003). I tested this transformation in SpatiaLite simply using the Spatial Reference Systems stored in spatial_ref_sys table; so I executed the SQL command

UPDATE my_table SET geometry_field = Transform(geom4326, 3003);

where “geom4326” is the geometry field recording the geometries of my points in WGS84 and “3003” is the EPSG value for Gauss-Boaga Rome40 W. The outcome was not good: the points converted were located till 80 meters far away from the correct position.
In order to reduce this displacement, I read this post of Flavio Rigolon about reprojection with ogr2ogr and I adapted that solution for SQLite/SpatiaLite (but I think it could work also with PostGIS in similar way).
In particular, I added a new Spatial Reference System (SRS) in spatial_ref_sys table:

INSERT INTO spatial_ref_sys VALUES(30033003,'epsg',30033003,'Veneto 3003','+proj=tmerc +ellps=intl +lat_0=0 +lon_0=9 +k=0.999600 +x_0=1500000 +y_0=0 +units=m +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68','');

My new SRS is identified by SRID and EPSG value “30033003”, is called “Veneto 3003” and has the same geodetic attributes (projection, ellipsoid, units, etc.) of Gauss-Boaga Rome40, but with the addition of 7 trasformation parameters (translation + rotation + scaling) defined by attribute “towgs84”.
For testing precision of my new SRS I selected 5 points of Veneto Region identifiable in WGS84 maps and in Gauss-Boaga Rome40 maps (CTR = “Carta Tecnica Regionale” at scale 1:10.000). I transformed my points from WGS84 SRS (EPSG:4326) to Gauss-Boaga Rome40 SRS (EPSG:3003) and to my new SRS “Veneto 3003” (EPSG:30033003). In the following images you can estimate the different positions for points transformed respectively in global EPSG:3003 and in local EPSG:30033003.

These two simple plots visualize the displacement (in meters) between correct position and points transformed.
The min, max and mean value of x (longitude) error of transformation from EPSG:4326 to EPSG:3003 is: 18.57, 36.26, 23.23 meters;
the min, max and mean value of y (latitude) error of transformation from EPSG:4326 to EPSG:3003 is: 63.36, 71.95, 68.74 meters;
the min, max and mean value of x (longitude) error of transformation from EPSG:4326 to EPSG:30033003 is: 0.49, 15.14, 4.31 meters;
the min, max and mean value of y (latitude) error of transformation from EPSG:4326 to EPSG:30033003 is: 3.3, 11.6, 6.8 meters.

[Part of this error is due to my test data: the 5 points in WGS84 have been selected from Googleearth and not recorded with a GPS and the same points identified in CTR are affected by the resolution of paper maps (“errore di graficismo” in Italian). I hope to do a more accurate test in the coming months...].

A mean error between 4 and 7 meters is acceptable for my purposes and in general for many archaeological works: in fact this error is not far from the best accuracy of portable GPS device (often used in archaeological surveys) and certainly smaller than positioning inaccuracy of many archaeological sites found in 19th or in the first half of 20th century. More accurate parameters of transformation (the 7 roto-traslation and scaling parameters of towgs84) could reduce this error, in particular in the Western and Northern part of Region where the distance from correct position seems to be greater.

That's all. If you know other (and faster) methods or if you detect mistakes in my post, please let me know. Any suggestions are welcome.

Denis Francisci

P.S. To enlarge the first image, open it in a new tab or window!


  1. Thank you for your post, it sounds very interesting! I had this problem of re-projection few months ago, between GPS collected data, as shapefiles in WGS84 UTM 33 N (epsg 32633)to be made suitable for Friuli Technical chart, which is projected in Rome 1940 (epsg 3004). In order to make this roto-translation between the two different map data, I found a good solution by using GVSiG geoprocess toolbox-data conversion-reproject. Here I could set my target projection (3004) by enabling an EPSG transformation 'WGS 84 to Monte Mario' n. 4 (for inland Italy). In this way I could easily visualize my GPS collected point on the Regional map of Friuli. To be honest, I didn't make an accurate measurement of the overall error rate, but everything looked like it was very precise. Ciao!

  2. Thank you for your comment.
    GvSIG's geoprocess toolbox-data is one of those "GIS tools" for shapefiles that I quoted in my post, at the beginnig. But I tested it with my data and the outcome was not good: my 5 points were shifted about 165 m from the correct position. On the other hand, I observed that the error seems constant, so the things are 2: either I made a mistake in processing my data or there is an error in GvSIG transformation parameters for Veneto Region. But if error is really constant (it should be checked carefully), the correction is easy to do with a simple traslation.

    Thank's again,


BlogItalia - La directory italiana dei blog Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.