I have data in EPSG 4978 (3D Cartesian XYZ using WGS84) and just for kicks, I tried projecting it to 4326 (lon, lat 2D using WGS84). I expected an error but lo and behold, I got a point back.

Here's my query to verify that my point is EPSG 4978:

=>select st_astext(pos_geom) from pos.pos_ts limit 1;
 POINT Z (1427635.07972 -5672506.90998 2534091.68628)

Attempt at transformation:

=> select st_astext(st_transform(pos_geom, 4326)) from pos.pos_ts limit 1;
 POINT Z (-75.8734015076523 23.5640490271681 -20.0468848655)

Like what?! My first reaction was that the output was probably garbage (-20.04688?) but when I use an external library to do the same transformation, it appears that the lon lat values are correct. So my question is twofold:

  1. What is PostGIS doing? AFAIK this behavior, while useful, violates the EPSG standard for 4326. 4326 is a 2D CRS with no Z coordinate in the spec.
  2. Please oh please tell me that the Z coordinate is elevation relative to the ellipsoid! I want it to be true but can't find it documented and my external projection method doesn't return elevation.
  • It is ellipsoid height.
    – mkennedy
    Jun 21, 2018 at 17:12

1 Answer 1

  1. Because it is practical then perhaps you can consider that PostGIS does not do 3D that violates EPSG:4326 but rather 2.5D where Z is some unitless value for height? Z is unitless because the vertical component is not defined by EPSG:4326 but I guess it is meters by default. At least Proj4 has a parameter +vto_meter Vertical conversion to meters https://proj4.org/usage/transformation.html.

  2. Proj.4 seems to handle EPSG:4326 as it was EPSG:4979, using ellipsoid height on top of EPSG:4326 that should make you happy. See discussion in https://github.com/OSGeo/proj.4/issues/394.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.