Chain vertical CRS transformations through intermediate same-datum vertical CRS#4708
Merged
rouault merged 10 commits intoOSGeo:masterfrom Mar 13, 2026
Merged
Conversation
…te vertical CRSs sharing a datum with the source or target
rouault
reviewed
Mar 11, 2026
Member
rouault
left a comment
rouault
left a comment
There was a problem hiding this comment.
is this generated with LLM ? Asking because the use of non ASCII characters like ↔ is quite typical of them. We have a checkbox in the pull request template about AI/LLM usage. It must be ticked when appropriate
test/unit/test_operationfactory.cpp
Outdated
| // The pipeline should contain axisswap (depth→height) and geogoffset | ||
| auto projStr = | ||
| list[0]->exportToPROJString(PROJStringFormatter::create().get()); | ||
| EXPECT_TRUE(projStr.find("geogoffset") != std::string::npos) << projStr; |
Member
There was a problem hiding this comment.
would be more convincing to test the whole pipeline string
Contributor
Author
There was a problem hiding this comment.
@rouault
Good point, thanks. Full pipeline is now added.
Contributor
Author
Yes, this code was developed with assistance from an LLM, and I forgot to check the box. I will remove the non-ASCII characters and update the PR description. Thanks for pointing that out |
rouault
reviewed
Mar 12, 2026
rouault
reviewed
Mar 12, 2026
rouault
force-pushed
the
fix/vert-to-vert-operations-chaining
branch
from
359e734 to
b7071f0
Compare
rouault
approved these changes
Mar 13, 2026
rouault
added a commit
that referenced
this pull request
Mar 13, 2026
…e same-datum vertical CRS (#4711) Chain vertical CRS transformations through intermediate same-datum vertical CRS (#4708) ## Summary When transforming between two vertical CRSs and no direct registered operation exists for the exact pair, PROJ now searches for registered operations involving an intermediate vertical CRS that shares the same datum as the source or target. The intermediate CRS may differ in axis direction (height vs depth), units (metres vs feet), or both. Previously PROJ fell back to a ballpark transformation, discarding available registered operations. - ✅ Closes #4707 - ✅ Tests added - [x] Developed with AI-assistance (Claude Opus 4.6) ## Example **EPSG:5705** (Baltic 1977 height) → **EPSG:5706** (Caspian depth) EPSG:5438 transforms 5705 → 5611 (Caspian *height*). CRS 5611 and 5706 share the Caspian datum but differ in axis direction. PROJ now composes: `5705 →(EPSG:5438)→ 5611 →(height-to-depth axisswap)→ 5706` ### Before (ballpark fallback) > ``` > +proj=affine +s33=-1 > (50.0, 40.0, 100) → (50.0, 40.0, -100.0) ← wrong > ``` ### After (registered operation + axis conversion) > ``` > +proj=pipeline +step +proj=geogoffset +dh=28 +step +proj=axisswap +order=1,2,-3 > (50.0, 40.0, 100) → (50.0, 40.0, -128.0) ← correct > ```
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When transforming between two vertical CRSs and no direct registered operation exists for the exact pair, PROJ now searches for registered operations involving an intermediate vertical CRS that shares the same datum as the source or target. The intermediate CRS may differ in axis direction (height vs depth), units (metres vs feet), or both. Previously PROJ fell back to a ballpark transformation, discarding available registered operations.
Example
EPSG:5705 (Baltic 1977 height) → EPSG:5706 (Caspian depth)
EPSG:5438 transforms 5705 → 5611 (Caspian height). CRS 5611 and 5706 share the Caspian datum but differ in axis direction. PROJ now composes:
5705 →(EPSG:5438)→ 5611 →(height-to-depth axisswap)→ 5706Before (ballpark fallback)
After (registered operation + axis conversion)
Implementation
New method
createOperationsVertToVertWithIntermediateVertincoordinateoperationfactory.cpp, using two strategies:This mirrors the existing
createOperationsGeogToVertWithIntermediateVert(geographic→vertical paths) but extends it to vertical→vertical paths. Uses the existingfindCandidateVertCRSForDatuminfrastructure.Changes
src/iso19111/operation/coordinateoperationfactory.cpp: AddedcreateOperationsVertToVertWithIntermediateVertmethod with anti-recursion guard; invoked fromcreateOperationsFromDatabaseWithVertCRSwhen no direct result is found.test/unit/test_operationfactory.cpp: Two new tests — Strategy 1 (5705→5706, height→depth) and Strategy 2 (5706→5705, depth→height).NEWS.md: Added entry under 9.8.0 Updates.docs/source/operations/operations_computation.rst: Updated "Vertical CRS to a Vertical CRS" section documenting the new intermediate CRS pivot logic.