2

I am checking effects of reprojecting planar coordinates from one CRS to another and back, keeping the same DATUM, and I was trying to determine the cause of the loss of precision.

I know that deformation grows to infinite values, and that precision will be lost eventually, but I was surprised to see differences in nearby zones. Am I correct to state that it is due to coordinates projected to far-out zones to grow in number size thus limiting the number of decimal places available in double precision arithmetics?

My version of Postgis and linked libraries: POSTGIS="2.3.3 r15473" GEOS="3.4.2-CAPI-1.8.2 r3921" SFCGAL="1.3.0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.1, released 2013/08/26" LIBXML="2.9.1" LIBJSON="0.11.99" TOPOLOGY RASTER

Below a reproducible example:

select *   from (SELECT 'original f32' as crs, ST_x( 
ST_GeomFromEWKT('SRID=32632;POINT(500000.0 4000000.00000 0)')) as forward, ST_x( 
ST_GeomFromEWKT('SRID=32632;POINT(500000.0 4000000.00000 0)')) as back
UNION
SELECT 'original f32->f33->f32' as crs, ST_x(st_transform( 
ST_GeomFromEWKT('SRID=32632;POINT(500000.0 4000000.00000 0)'),32633)) as forward, 
ST_x(st_transform(st_transform( 
ST_GeomFromEWKT('SRID=32632;POINT(500000.0 4000000.00000 0)'),32633),32632)) as back
UNION 
SELECT 'original f32->f34->f32' as crs, ST_x(st_transform( 
ST_GeomFromEWKT('SRID=32632;POINT(500000.0 4000000.00000 0)'),32634)) as forward, 
ST_x(st_transform(st_transform( 
ST_GeomFromEWKT('SRID=32632;POINT(500000.0 4000000.00000 0)'),32634),32632)) as back
UNION 
SELECT 'original f32->f35->f32' as crs, ST_x(st_transform( 
ST_GeomFromEWKT('SRID=32632;POINT(500000.0 4000000.00000 0)'),32635)) as forward, 
ST_x(st_transform(st_transform( 
ST_GeomFromEWKT('SRID=32632;POINT(500000.0 4000000.00000 0)'),32635),32632)) as back
) a order by crs
  • 1
    I think you need to be more explicit about what problem you are seeing. For me, the "back" column reads '500000' in all four rows, which is almost suspiciously good... – Ture Pålsson Feb 12 '18 at 11:24
  • 1
    For me the values of "back" are 500000, 499999.999878563, 500000.083640183, 500004.57534727, respectively. Seems to be rather old system with PostGIS 2.1 and Proj4 4.8.0. – user30184 Feb 12 '18 at 13:53
  • 3
    Anyone know when proj.4 switched to a more precise transverse Mercator algorithm? This is specifically a transverse Mercator problem. The standard algorithm has a problem with the inverse--it's not as precise as the forward. There are various alternative algorithms and ways to improve the usual one. – mkennedy Feb 12 '18 at 21:53
  • @mkennedy I added info on version of libraries; – Francesco Feb 13 '18 at 14:04
  • @user30184 those are also my results, and that is the proj. version I have, I will update and test with a new version and will probably get the same result as Ture – Francesco Feb 13 '18 at 14:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.