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" <[email protected]> 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 [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user
