[Proj] Misplaced SHP obtained with PROJ 4.8.0 called from gvSIG CE

[Andre Joost]

Am 27.08.2013 19:24, schrieb Jorge Arevalo:
 > Ok, my example is not a good one for the general case I want to cover.
 > So, my previous question: what should I do to make PROJ.4 happy in
 > case my client (gvSIG CE) doesn't provide nadgrids/toWGS84? For
 > example, if I ask for EPSG:23030 and I get this PROJ.4 string (as is
 > at http://spatialreference.org/ref/epsg/23030/proj4/)
 >
 > +proj=utm +zone=30 +ellps=intl +units=m +no_defs
 >

No, thats not correct. QGIS works with this string:
+proj=utm +zone=30 +ellps=intl +towgs84=-87,-98,-121,0,0,0,0 +units=m
+no_defs

If you have no access to the grid file, look for +towgs84 parameters.
Omitting them would be interpreted as +towgs84=0,0,0,0,0,0,0.
And if that was correct, nobody would have build the nadgrid file.


 > Or ask for EPSG:25830 and get
 >
 > +proj=utm +zone=30 +ellps=GRS80 +units=m +no_defs

here we have in QGIS:
+proj=utm +zone=30 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
towgs84 parameters are all zero because GRS80 and WGS84 ellipsoids are
located at the same point.

 >
 > Do I have to add datum transformation info just to destination SRS 
string?
 >

No, always in both! At least the null or 0,0,0,0,0,0,0

The information on spatialreference.org is often outdated, because
nobody really cares about it. Proj4 gets regular updates from the EPSG
database (almost the bible in projections and transformations), but
there is no updating mechanism for sr.org.

GDAL;QGIS and postgis work with the latest Proj4 data, and its up to
openlayers and other second-class-software who look up transformation on
sr.org believing that someone might keep the information current.


-- 
Gruß,
André Joost