Closed jamiecook closed 2 months ago
Geocentric systems need 3D coordinates. Try with (153, -27, 0)
instead of (153, -27)
. That will produce a meaningful 3D coordinate that makes sense as input for the geocentric system.
Right - i guess that makes sense.
I guess it's outside scope for this forum - but any suggestions on how that would be applied to a GeoDataFrame where all my geometries are 2D?
Why do you want to use a geocentric system if your data is 2D? A geographic CRS is not enough?
I was looking for a cartesian system that had good coverage of the entire Australian continent - MGA2020 works okay within each zone - but i have an "all of Aus" dataset that I wanted to do some buffering operations with.
Now that you highlight it, there were probably other better options, but I was nerd-sniped by the unexpected behaviour here.
a cartesian system that had good coverage of the entire Australian continent
Australia is not Austria (sorry, I had to make the joke). I mean, it is huge! A Cartesian 2D would be projected... with a lot of distortion due to the size of Australia. Ok, Geocentric is also Cartesian, but you are opening another Pandora's box: it is a 3D system, so all your coordinate management should support that.
Possibly related: OSGeo/PROJ#2318
May be worth trying with a 3D geographic CRS (EPSG:4979).
@jjimenezshaw is there a reason why pyproj will let you transform 2d data via a geocentric crs if 3d inputs are required?
After some experimenting I understand in this case the issue is because (153, -27) is converted to (-5067052.801, 2581792.356), when it really should be (-5067052.801, 2581792.356, -2878215.576) in the first transformation, and it is the missing z coordinate (which is treated as zero) responsible for this failing to round trip in the second transformation.
If there's a reason for pyproj to support this, then perhaps there's a case to prevent/ warn on these transformations e.g. at a geopandas level in this case - if there's an easy way to classify a crs / transformation as non-applicable from 2d to 3d (I imagine geocentric transformations might not be the only kind in this situation?)
This is most likely a user error - but we've had two experienced GIS users scratching their heads on this one. We appear to be getting a bad transformation out of the MGA projections of Australia.
Code Sample (copy-pastable)
Problem description
So taking a point (which is in the defined bounds of the cartesian projection system) and going from WGS84, into that projection system and back out again should give (roughly) the same point.
This property holds for projected WGS84 (3857) and for Map Grid of Australia (MGA2020:7856), but does not hold for GDA projections (GDA94 'epsg:4348', GDA2020 'epsg:7842') both of which are geo-centric.
Expected Output
Environment Information
Installed with pip