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

Hermann Peifer peifer at gmx.eu
Wed Aug 21 13:15:03 EST 2013

On 2013-08-21 17:04, Jorge Arevalo wrote:
> Hello,
> I'm trying to fix a bug related with PROJ in gvSIG CE. This desktop
> client creates its own JNI wrapper, based on PROJ sources. The
> reprojection of shapefiles using grid files works with the wrapper
> based on PROJ 4.5.0, but it fails if we construct the same wrapper
> based on any upper version of PROJ (PROJ 4.8.0, for example).
> Here, the use case that causes the problem:
> - We want to reproject this shapefile from epsg:23030 to epsg:25830:
> https://dl.dropboxusercontent.com/u/6599273/gis_data/EPSG23030_data.zip
> - We want to use this grid file to perform the operation:
> https://dl.dropboxusercontent.com/u/6599273/gis_data/sped2et.gsb
> The operation done with the JNI wrapper based on PROJ 4.5.0 works
> fine. But if we use PROJ 4.8.0 as base, we get a misplaced file. Here,
> a screenshot. In blue, the original shapefile. In green, the shapefile
> correctly reprojected (PROJ 4.5.0). In red, the misplaced shapefile
> (PROJ 4.8.0)
> https://dl.dropboxusercontent.com/u/6599273/errors/gvsigce/gvsigce_misplacing_reproj.png
> Debugging, we found the problem is in pj_transform.c. I guess it's
> related with the way we pass information to PROJ functions. I've made
> a diff between both versions (pj_transform in PROJ 4.5.0 and PROJ
> 4.8.0), but I see several changes, and I don't know where to focus.
> Any clue?
> Many thanks in advance, and best regards,

I assume that this is your definition of the target SRS:

+proj=utm +zone=30 +ellps=GRS80 +units=m +no_defs

if yes, you'd have to change it to:

+proj=utm +zone=30 +ellps=GRS80 +nadgrids=@null +units=m +no_defs

Further reading: Why do I get different results with 4.5.0 and 4.6.0?


More information about the Proj mailing list