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
_______________________________________________
postgis-users mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/postgis-users
