Ticket #1742 (closed defect: invalid)

Opened 15 months ago

Last modified 15 months ago

PostGIS 2.0 alters Z-coordinate

Reported by: pramsey Owned by: pramsey
Priority: critical Milestone: PostGIS 2.0.0
Component: postgis Version: 2.0.x
Keywords: Cc:

Description

This query

select                        
st_asewkt(st_transform(st_geomfromtext(
'POINT (700000 4500000 100)',23030), 4326));

returns a z value of 168.25 under PostGIS2.0+Proj4.8 and a value of 100 under PostGIS1.5+Proj4.8. So the problem is not necessarily proj only.

Change History

Changed 15 months ago by lrssvt

  • summary changed from Proj 4.8 + PostGIS 2.0 alters Z-coordinate to PostGIS 2.0 alters Z-coordinate

I get the same issue with PROJ 4.7.

"POSTGIS="2.0.0rc2SVN r9583" GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.7.1, 23 September 
2009" GDAL="GDAL 1.9.0, released 2011/12/29" LIBXML="2.7.8" TOPOLOGY RASTER"

Changed 15 months ago by pramsey

Mystery solved, it is nothing more mysterious than that PostGIS 2.0 uses this as the definition of EPSG:23030:

+proj=utm +zone=30 +ellps=intl +towgs84=-87,-98,-121,0,0,0,0 +units=m +no_defs

and PostIGIS 1.5 uses this

+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

Hey presto, there's an ellipsoid shift in there, so the X and Y coordinates also differ between versions. The killer though is that yes, Proj4.8 is now doing a Z-shift too, so the question becomes, what should we do with Z?

Changed 15 months ago by pramsey

Er, edit, PostGIS 2.0 uses this for EPSG:23030

+proj=utm +zone=30 +ellps=intl +towgs84=-87,-98,-121,0,0,0,0 +units=m +no_defs

and PostGIS 1.5 uses this

+proj=utm +zone=30 +ellps=intl +units=m +no_defs 

Anyways, the problem is as described. We're getting a grid shift, and Proj4.8 does the vertical shift as well as the horizontal.

Changed 15 months ago by pramsey

Edit again: not a grid shift, but an ellipsoid shift. (Too much|not enough) coffee.

Changed 15 months ago by pramsey

  • status changed from new to closed
  • resolution set to invalid

Thanks to lrssvt, right, you got it. So actually there is no regression here at all, this is "expected" behavior and this ticket should be re-filed as a a future enhancement to allow users to optionally skip z-transformation.

Changed 15 months ago by pramsey

Oh, and a note to the original poster, you can get back the "old" behaviour (not doing an ellipsoid shift, even though one should be applied) by changing the proj4text in your spatial_ref_sys table and removing the to_wgs84 parameter.

Changed 15 months ago by lrssvt

Well, but the +towgs84 should not have been there! I guess that is correct the SRID of 1.5 according to EPSG[1], even if less accurate for the coordinates X and Y.

[1] -  http://spatialreference.org/ref/epsg/23030/

Changed 15 months ago by lrssvt

+towgs84 parameter depends on the area where you are, within the UTM zone 30. So it is at the discretion of the user who uses! For example, for Italy with EPSG:3004 or 3003, it is:

+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68	 Italy (Peninsular Part), Accuracy 3-4m
+towgs84=-168.6,-34.0,38.6,-0.374,-0.679,-1.379,-9.48	 Italy (Sardinia), Accuracy 3-4m
+towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08	 Italy (Sicily), Accuracy 3-4m

PostGIS 2.0 uses this:

+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68

so, for Sardinia that leads to gross errors!

Note: See TracTickets for help on using tickets.