[postgis-users] transformation discrepancy with postgis v. cs2cs

[Bryan Keith]

Turns out ArcMap's transformation on-the-fly does the same thing as cs2cs.
 What is postgis' transform doing differently?

Bryan

> Hello,
>
> I'm not sure if this is the correct list for this question, but here goes.
>  If I ought to post to another list, please let me know which one.
>
> I'm seeing a discrepancy between coordinate transformations in postgis and
> transformations using cs2cs with the exact same proj.4 string.  Here are
> the proj.4 strings and transformation using postgis:
>
> select proj4text from spatial_ref_sys where srid = 32003;
> proj4text
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  +proj=lcc +lat_1=46.4 +lat_2=44.86666666666667 +lat_0=44 +lon_0=-109.5
> +x_0=609601.2192024384 +y_0=0 +ellps=clrk66 +datum=NAD27
> +to_meter=0.3048006096012192 +no_defs
> (1 row)
>
> select proj4text from spatial_ref_sys where srid = 32100;
> proj4text
> --------------------------------------------------------------------------------------------------------------------------
>  +proj=lcc +lat_1=49 +lat_2=45 +lat_0=44.25 +lon_0=-109.5 +x_0=600000
> +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs
> (1 row)
>
> select astext(transform(setsrid(makepoint(1234488, 744181), 32003),
> 32100));
>                   astext
> ------------------------------------------
>  POINT(366770.791392722 199138.151643548)
>
> Here is the transformation using cs2cs:
>
> cs2cs +proj=lcc +lat_1=46.4 +lat_2=44.86666666666667 +lat_0=44
> +lon_0=-109.5 +x_0=609601.2192024384 +y_0=0 +ellps=clrk66 +datum=NAD27
> +to_meter=0.3048006096012192 +no_defs +to +proj=lcc +lat_1=49 +lat_2=45
> +lat_0=44.25 +lon_0=-109.5 +x_0=600000 +y_0=0 +ellps=GRS80 +datum=NAD83
> +units=m +no_defs
> 1234488  744181
> 366704.35       199132.53 0.00
>
> Why the discrepancy?  I'm guessing it has something to do with how datum
> shifts are handled.  So which one is right?  That's probably going to
> depend on something that I don't know about my input data, but maybe
> someone will enlighten differently.  Thank you.
>
> Bryan
>