[postgis-users] PostGIS & PROJ 6 -- Y axis shift with 900913

[Jeff McKenna]

For the history of this: I first reported this shift back in 2018 
(http://lists.maptools.org/pipermail/proj/2018-February/008082.html). 
It was fixed for 3857 in the PROJ 5.2.0 release.

My advice to you is to change to using EPSG:3857 as most software now no 
longer supports the non-standard "900913".

-jeff



-- 
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/





On 2020-07-20 3:25 p.m., Shira Bezalel wrote:
> We recently recompiled PostGIS in one of our Postgres 12.3 environments 
> with PROJ 6 (6.3.2) from PROJ 4 (4.9.3).
> 
> postgis_full_version() output:
> POSTGIS="3.0.1 ec2a9aa" [EXTENSION] PGSQL="120" GEOS="3.7.1-CAPI-1.11.1 
> 27a5e771" PROJ="6.3.2" LIBXML="2.9.4" LIBJSON="0.12.1"
> 
> We're now noticing that using ST_Transform(geometry, srid)**to transform 
> some points in California from SRID 4326 to 900913 is causing a shift 
> along the Y axis of about 20-30 meters. The difference is evidenced by a 
> comparison of the old and new ST_Y() values.
> 
> If I force the PROJ 4 definition to be used, the transformation works 
> fine with no shift. (To force the PROJ 4 definition, I used the method 
> described in 
> http://blog.cleverelephant.ca/2019/02/proj4-postgis.html and set 
> authname, authsrid and srtext to null so that the proj4text column is used.)
> 
> Is this shift expected with PROJ 6? I realize 900913 is deprecated and 
> we plan to migrate to 3857 as a longer term solution, but looking for 
> a shorter term fix if possible since much data and code is impacted by 
> this. Note we are seeing no shift issues with SRID 3857.
> 
> Let me know if I can provide more information.
> 
> Thanks much,
> Shira
>