PostGIS and Proj4 difference for EPSG:28356

[mtrcn]

Hello, there are a few meters of difference in the coordinate transformation between Proj4js and PostGIS with the same Proj4 definitions.

https://jsfiddle.net/4drm5v07/ is a sample code where I test the difference.

To make the same transformation in PostGIS, I use the following SQL;

select st_transform(ST_SetSRID(ST_Point(515137.96, 6937915.52), 28356), 3857)

Here is the result from both calculations;
Proj4
X : 17048971.316437162 Y : -3209051.731103003

PostGIS
X: 17048971.98361579 Y: -3209050.1545588113

There is a 0.66m difference in X and a 1.6m difference in Y.

I'm not sure whether is a bug or not but I spent a lot of time on this but I couldn't find a solution. I also compared Proj4js results with ArcGIS, QGIS and epsg.io and they all give the same result as PostGIS.

PostGIS and Proj4js use the same Proj4 string.

[ahocevar]

There are different transformations available for EPSG:28356. You chose one without datum transformation in your fiddle. I guess PostGIS and QGIS use one with grid shift transformation. You can do that too with proj4.js, but you'll have to obtain and configure the grid shift file.

[mtrcn]

Hello @ahocevar, I especially checked if PostGIS and Proj4JS strings are the same or not. They are both the same based on the spatial_ref_sys table.

I exported the record from the DB for you to check;

INSERT INTO public.spatial_ref_sys (srid,auth_name,auth_srid,srtext,proj4text) VALUES
	 (28356,'EPSG',28356,'PROJCS["GDA94 / MGA zone 56",GEOGCS["GDA94",DATUM["Geocentric_Datum_of_Australia_1994",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6283"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4283"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",153],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",10000000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","28356"]]','+proj=utm +zone=56 +south +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs ');

[ahocevar]

According to https://epsg.io/28356, the accuracy of this transform is 3 meters. So we're well within tolerance.

[mtrcn]

Based on transformation matrice's property could be acceptable but when you use the layer based on Proj4JS with an ESRI layer, then the difference is remarkably disturbing as below. It doesn't have to be ESRI, it will be the same with other layers sourced from PostGIS and QGIS etc.

[ahocevar]

In this case I would suggest using a grid transform on both ends, then you'll get more accurate results. Or you could compare the implementations on the source code level and provide a pull request with a fix.

[mtrcn]

I finally found the problem, it seems Helmert parameters are different. If I use the following sting; +proj=utm +zone=56 +south +ellps=GRS80 +towgs84=0.06155,-0.01087, -0.04019,0.0394924,0.0327221,0.0328979,-0.009994 +units=m +no_defs it generates the same result. I found these parameters from https://www.agisoft.com/forum/index.php?PHPSESSID=hvnd91e449micv2h956ovprctq&topic=12063.msg53942#msg53942

Yellow is Proj4JS transformed geometry, red is ESRI geometry.

I also realized that these parameters have been in QGIS already but I was not realized;

I wonder how QGIS got these parameters while all EPSG databases have the wrong parameters such as epsg.io.

[ahocevar]

Nice, so can we close this?

[mtrcn]

Yes, I think we can close it.