[Proj] Misplaced SHP obtained with PROJ 4.8.0 called from gvSIG CE
Jorge Arevalo
jorge.arevalo at geomati.co
Tue Aug 27 12:24:17 EST 2013
On Mon, Aug 26, 2013 at 7:25 PM, Hermann Peifer <peifer at gmx.eu> wrote:
> On 2013-08-26 18:43, Jorge Arevalo wrote:
>>
>>
>> Ok, so, if I didn't misunderstand:
>>
>> - These proj strings should be valid for epsg:23030 to epsg:25830
>> transformation using mentioned grid file:
>>
>> source SRS: +proj=tmerc +lat_0=0.0 +lon_0=-3.0 +k=0.9996 +x_0=500000.0
>> +y_0=0.0 +ellps=intl +units=m +nadgrids=@sped2et.gsb +no_defs
>
>
> I never heard of the "@gridshiftfile.gsb" option. I only use
> +nadgrids=gridshiftfile.gsb (if the file is where PROJ expects it to be, on
> my MacBook at /opt/local/share/proj/) or
> +nadgrids=/path/to/gridshiftfile.gsb
>
Yes, sorry. My fault. A writting mistake.
>
>>
>> destination SRS: +proj=tmerc +lat_0=0.0 +lon_0=-3.0 +k=0.9996
>> +x_0=500000.0 +y_0=0.0 +ellps=GRS80 +units=m +nadgrids=@null +no_defs
>>
>> (not sure about the need of +no_defs part, but included just in case)
>
>
> +no_defs is not needed in the above case.
>
>
>> - These proj strings should be valid for the same transformation, but
>> without using any grid file:
>>
>> source SRS: +proj=tmerc +lat_0=0.0 +lon_0=-3.0 +k=0.9996 +x_0=500000.0
>> +y_0=0.0 +ellps=intl +units=m +nadgrids=@ null +no_defs
>>
>> destination SRS: +proj=tmerc +lat_0=0.0 +lon_0=-3.0 +k=0.9996
>> +x_0=500000.0 +y_0=0.0 +ellps=GRS80 +units=m +nadgrids=@null +no_defs
>
>
> If you have +nadgrids=@null on both sides (source and target SRS), then no
> actual transformation will be made.
>
Ok. So, in case both SRS (source and destination) lack of datum
transform information (no +nadgrids, no +toWGS84), what should be
done, to be "PROJ.4 correct"? Just the destination SRS must include
the datum information (nadgrid/toWGS84)?
Sorry if the question sounds silly. I don't have a lot of experience with PROJ.4
>
>> And the important thing about the change PROJ.4 4.5.0 to PROJ.4 >=
>> 4.6.0 is that PROJ.4 version >= 4.6.0 needs a datum specification for
>> *both* source SRS and target SRS in order to "make the datum shift".
>> So, in the case I don't have a datum specification by default, I
>> should *always* add +nadgrids=@null or +toWGS84=0,0,0.
>>
>
> Hmm. Blindly adding +nadgrids=@null or +toWGS84=0,0,0 would actually bring
> you back to PROJ 4.5.0 behaviour, and I doubt if you want this. At the time,
> the PROJ developers had good reasons for changing the behaviour of PROJ
> version >= 4.6.0.
>
> However, in your example case the target datum is ETRS89 which is
> practically identical with WGS84, so using +nadgrids=@null or +toWGS84=0,0,0
> is appropriate.
>
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
Or ask for EPSG:25830 and get
+proj=utm +zone=30 +ellps=GRS80 +units=m +no_defs
Do I have to add datum transformation info just to destination SRS string?
Many thanks again for your help!
Jorge
> Hermann
>
--
Jorge Arévalo
http://geomati.co
More information about the Proj
mailing list