[Qgis-user] Difference: EPSG 3004 - EPSG 102092

[b.j.kobben at utwente.nl]

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-paul at 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
>
>
>
>
>
>