you don't have to change the CRS in the Metadata tab.
You have to change the reference system from the "Add layer" window,
before accepting, before adding it on the View. When you have the
layer at the "Add layer" window you have to access to the
"Properties" option of that window and select its reference system
(if the SHP file has a PRJ file you don't need to select it because
ESRI and EPSG codes are independent, and they are working good, with
their correct parameters. If your layer is a concrete EPSG code, you
have to select it, but if it's in a concrete ESRI code you have to
select the ESRI code.
El 28/06/17 a las 12:19, Associação de
Municípios TERRAS DO INFANTE escribió:
---------- Forwarded message ----------
From: Associação de Municípios
TERRAS DO INFANTE<[hidden email]>
Date: 2017-06-27 16:42 GMT+01:00
Subject: Projections for Portugal
To: [hidden email]
I just downloaded your testing version, build 2827, and
found that ESRI projection 102164 is being interpreted by
gvSIG as EPSG:5018, which is an error.
In fact, ESRI:102164 shall be interpreted by gvSIG as
> I just downloaded your testing version, build 2827, and found that ESRI
> projection 102164 is being interpreted by gvSIG as EPSG:5018, which is
> an error.
I'm agree, it's a wrong assumption based on SRS name similarity.
> In fact, ESRI:102164 shall be interpreted by gvSIG as EPSG:20790.
Geodesically speaking, ESRI:102164 and EPSG:20790 are two different
SRSs, even if they looks very similar, for two reasons: firstly they
adopt different prime meridians (respectively Greenwich and Lisboa),
secondly ESRI:102164 doesn't consider the transformation parameters
towards WGS84 (like all ESRI SRSs and it was in the past for all prj).
So gvSIG doesn't relate them correctly, because they're not equivalent
Operationally speaking, instead, because their projected coordinates are
the same, the user could set EPSG:20790 manually at the moment, as
Mario has well explained in the previous email.
It's clear that projection file recognition in gvSIG could be further
improved including also ESRI codes, but the transformation parameters
would be missing in that case. So I think that ESRI codes should be
remapped as EPSG ones in order to take full advantage of transformation
parameters and avoid unwanted data shifts.