[Proj] Misplaced SHP obtained with PROJ 4.8.0 called from gvSIG CE
Hermann Peifer
peifer at gmx.eu
Wed Aug 21 11:15:03 PDT 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?
http://trac.osgeo.org/proj/wiki/FAQ#WhydoIgetdifferentresultswith4.5.0and4.6.0
Hermann
More information about the Proj
mailing list