[Proj] Problems with the Transformation of Coordinates for Cuba

[Pablo Velazco Villares]

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