[Proj] Problems with the Transformation of Coordinates for Cuba

Wed Feb 10 03:59:37 PST 2010

Hello,
it seems you want to use the datum shift 

    EPSG:15978, "NAD27 to WGS 84 (88)",

which has Area of Use = Cuba. (See http://www.epsg-registry.org ) 

When you write 

    +towgs84=2.478, 149.752, 197.726, -0.526356, -0.497970, 0.500831, 0.685238

you have the same numerical values as EPSG, but you have more decimals.

However, there are two opposite sign conventions for the 
three rotations, known as the Position Vector Transform 
and the Coordinate Frame Rotation.  

According to EPSG, "NAD27 to WGS 84 (88)" is 
published as a Coordinate Frame Rotation. But PROJ.4 
uses the opposite convention, so you must reverse the
signs of the rotations.  So, you get 

    +towgs84=2.478, 149.752, 197.726, 0.526356, 0.497970, -0.500831, 0.685238

instead.

I tried this with cs2cs, but I still got an error 
of 15.6 meters compared to your test point:

C:\Program Files\FWTools2.2.8>cs2cs +proj=longlat +ellps=clrk66 +towgs84=2.478,149.752,197.726,0.526356,0.497970,-0.500831,0.685238 +no_defs +to +proj=longlat +datum=WGS84
-76.64100612 20.371090164
76d38'26.713"W  20d22'17.928"N -22.240

(Error calculated on http://williams.best.vwh.net/gccalc.htm )

With your version, you got an error of 29.1 meters. 
So my answer is not the complete answer, since EPSG 
says the accuracy of the datum shift is 1 meter.  
(Even if this is the standard deviation (one sigma), 
I would not expect greater errors than 3 meters.)

Maybe your test point is wrong, or maybe the datum
shift is wrong. The EPSG information source for the
datum shift is 

   "Dictamen 2/05 de la Oficina Nacional de Hidrografia y Geodesia".

Regards,
--
Mikael Rittri
Carmenta AB
SWEDEN
www.carmenta.com

-----Original Message-----
From: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] On Behalf Of Pablo Velazco Villares
Sent: Wednesday, February 10, 2010 2:07 AM
To: proj at lists.maptools.org
Subject: [Proj] Problems with the Transformation of Coordinates for Cuba

Hello I am entering recently in the list, greetings to the colleagues.  

The process of migration of our space databases and applications GIS to platforms of Free Software, implies in occasions the necessity to repair in aspects that in the software proprietors, they were we quite transparent. The case that occupies me is a palpable example of what I comment them.    
The situation is the following one. I am from Cuba and our CRS in the EPSG they are the following ones: 3795: North Cuba, 3796: South Cuba, both for the work with plane coordinates, and the 4267 NAD27, for the case of the geographical ones. The CRS 4267 are the base for the CRS 3795 and 3796 and he has as DATUM the "Nad 27 Continental for US." 

In the case of the operations of CONVERSION OF COORDINATED: of 3795 at 3796 or 3796 at 4267 (in this case of plane to geographical) we achieve extremely precise results in the conversion, but it is not the case, when we carry out operations of TRANSFORMATION that imply the step the transformation of a DATUM to other, for example:  of NAD27 to WGS84.   
The problem is related, with the fact that the specific Datum doesn't exist for the area of Cuba and the local CRS they are inheriting the parameters of transformation of another region. The problem begins him to perceive when superimposing space layers as: GPS or Images of Goolgle (both in WGS84), have more than enough layers in local CRS.  

To exemplify the actions that we have carried out, we take like case of study the function Postgis:  ST_Transform and we carry out consultations like these, for the transformation tests. Select Astext(ST_Transform(ST_SetSRID ('point(-76.670120 20.388508) ':: geometry, 4267),4326));  
Previously we carry out the creation of a New SRID (4267001) in the chart: spatial_ref_sys of Postgis, with: proj4txt:  "+proj=longlat +ellps=clrk66 +towgs84=2.478, 149.752, 197.726, -0.526356, -0.497970, 0.500831, 0.685238 +no_defs ".   

As you it can appreciate, we eliminate the parameter +datum=NAD27, and we incorporate those (7) transformation parameters to WGS84 of our country for the method of Bursa-Wolfe. For what we have studied on the topic, we lack the treatment of the parameter +nadgrids, that which we have not been able to implement, because we lack information on the form of configuring an appropriate grill to our territory. In the Database of EPSG, the CRS 4267, they have registered the Variant: 88, the one which this associated to the transformation parameters to WGS84, before exposed, but we have not been able to give to this a practical sense that facilitates us to work with a NAD 27 for Cuba, as we had it in Mapinfo, for example:  "Longitude / Latitude (NAD 27 for Cuba_CNGPS) ", 1, 9999, 7, 2.478, 149.752, 197.726, -0.526356, -0.497970, 0.500831, 0.685238, 0  

So that they can help us, I include a group of test data:  
Point1 in NAD27 for Cuba    
Long: -76º 38' 28.0824" or in DD: -76.64100612    
Lat: 20º 22' 16.19" or in DD:  20.371090164    
Point1 in having Transformed correctly to WGS84
Long: -76º 38' 27.171" or in DD: -76.6408814349
Lat: 20º 22' 18.192" or in DD:  20.37172032737  

Point in plane coordinates "South Cuba" 3796
X: 520065.10m Y:190891.5m  

When carrying out the transformation operations in postgis (with the parameters before mentioned), we obtained the following erroneous results:  
Point1 become to WGS84 with postgis DD:  
Long: -76.6406516
Lat: 20.3718218
Transformed Point1 of WGS84 to South Cuba 3796 (plane coordinates):  
X: 520043.06m Y:190910.53m  

It is evident the great difference between the prospective results and those really reached ones.  
Excuse the extensive of the mail, but I didn't have another form of trying to make me to understand and to treat such a complicated problem.  
I request them collaboration, in the solution of this situation, their ideas will be of an useful helps for us.  
Greetings Mckensen
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj