Derived projected CRS related improvements#4667
Conversation
rouault
commented
Feb 8, 2026
- proj_factors(): make it work with derived projected CRS
- Add proj_create_linear_affine_parametric_conversion(), proj_create_derived_projected_crs(), proj_crs_add_horizontal_derived_conversion()
3741e45 to
1ef8e75
Compare
| " PARAMETER[\"B2\",3.2811679790026242,\n" | ||
| " SCALEUNIT[\"coefficient\",1],\n" | ||
| " ID[\"EPSG\",8641]]],\n" | ||
| " CS[Cartesian,2],\n" |
There was a problem hiding this comment.
As we know, in an "Affine parametric transformation" the axis order in the WKT is considered in a strange way.
What happens with a northing-easting system? And when A2 or B1 have non-zero values?
There was a problem hiding this comment.
What happens with a northing-easting system?
That PR doesn't change this behaviour. The axis order of the coordinate system of the derived projected CRS doesn't influence the computation. The CS of the derived projected CRS is mostly informative
And when A2 or B1 have non-zero values?
well just as documented:
- value of the first axis of the derived CRS = A0 + value of first axis of base CRS * A1 + value of second axis of base CRS * A2
- value of the second axis of the derived CRS = B0 + value of first axis of base CRS * B1 + value of second axis of base CRS * B2
| const PJ *conversion, | ||
| const PJ *coordinate_system); | ||
|
|
||
| PJ PROJ_DLL *proj_create_derived_projected_crs(PJ_CONTEXT *ctx, |
There was a problem hiding this comment.
How do these changes behave with proj_normalize_for_visualization?
There was a problem hiding this comment.
From what I can see, CRS::normalizeForVisualization() does act on a DerivedProjectedCRS, but I don't think that currently it has any effect on changing actual coordinate values.
93f3dd5 to
d63fe77
Compare
…rived_projected_crs(), proj_crs_add_horizontal_derived_conversion()
d63fe77 to
757c840
Compare