Hello,
this last piece of information made everything even clearer.
Really thanks to everybody who took time to anser.
Regards
Paolo
Il 07/11/2013 16:39, b.j.kob...@utwente.nl ha scritto:
As an added note: be aware that 102092 is NOT an actual EPSG code. EPSG
codes with no's > 32768 are not in the official EPSG database, and are in
actual fact therefore not EPSG codes really.
It's just that many softwares allow for the creation of user defined
Spatial Reference Systems, and to make them work in software that works
with EPSG codes, you can use an "unofficial" code > 32768 to define them.
The best-known example of that is the Pseudo-Mercator used by Google and
others which was given the user defined code 900913. When EPSG finally
officially sanctioned that SRS and put it into their database, it got the
EPSG code 3857...
Yours,
--
Barend Köbben
ITC - University of Twente
PO Box 217, 7500AE Enschede (The Netherlands)
+31-(0)53 4874 253
@barendkobben
On 07-11-13 16:09, "Paolo" <e-p...@tiscali.it> wrote:
I realize I still need to learn much.
Thanks for taking time to explain.
Paolo
Il 07/11/2013 14:59, G. Allegri ha scritto:
If I understand well, the datum shift parameters are required in order to
improve the accuracy of the conversion between 3004 and other RS as ED50
UTM33, while they are not needed for conversion between 102092 and e.g.
WGS84?
The shift parameters are alway needed to obtain higher precision for CRS
trasformations where the datums are different. When a transform from
datum A to datum B is required, Proj4 (the engine underlying SRS and
projections) does datum A -> WGS84 -> datum
B. The shift parameters (+towgs84) are used my Proj4 to manage the
intermediated transformations to (and from) WGS84, which is kind of a
"pivot CRS".
So, they're should be always employed. 102092 does not define them,
that's why you get worst results.
giovanni
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user
