Multi source terrain provider

[juunie-roh]

Description

This is an initial draft of migration from external library TypeScript implementation into Cesium development environment.

The naming conventions are not considered in this draft.

You can see the detailed description about this feature at the related issue, #12817.

Issue number and link

This PR relates to #12817.

Testing plan

You can see conducted unit tests at external library repository.

Author checklist

• [x] I have submitted a Contributor License Agreement
• [x] I have added my name to CONTRIBUTORS.md
• [ ] I have updated CHANGES.md with a short summary of my change
• [ ] I have added or updated unit tests to ensure consistent code coverage
• [ ] I have updated the inline documentation, and included code examples where relevant
• [x] I have performed a self-review of my code

[github-actions[bot]]

Thank you for the pull request, @juunie-roh!

:white_check_mark: We can confirm we have a CLA on file for you.

[juunie-roh]

There is a limitation in the current implementation:

• Cannot override higher zoom levels within configured terrain regions

For example:

• Level 15 region configured with Provider A
• Level 16+ in the same geographic area should use Provider B
• Currently: Level 16+ continues using Provider A

What causes this is:

• Simple region designation cannot change TerrainAvailability.
• Once a region matches, it returns immediately without checking further options.

This could be solved by nesting HybridTerrainProvider instances, but I'm not sure if it's the right direction.

I haven't deeply investigated this limitation yet, as it may be an edge case.

[ggetz]

Thanks for the PR @juunie-roh, and thanks for your patience!

Would you mind describing the use case(s) you're looking to address here? It seems like this PR address some, but not all, of the use cases we're looking into for https://github.com/CesiumGS/cesium/issues/12817. For instance, I don't believe this handles showing multiple terrain surfaces simultaneously.

However, it does appear like this could be useful for many users and would likely still be worth consideration.

[juunie-roh]

Hi, @ggetz ! 👋 You're right, that this is not for showing multiple terrains at once. My specific use case was to integrate terrains from different sources seamlessly. I set a global terrain fallback, then configured the specific area where needed to show terrain with different source.(higher resolution could be one of the example) This implementation solves the problem by delegating requestTileGeometry to different terrain providers based on tile coordinates and zoom levels.

https://juun.vercel.app/cesium-utils/terrain I have working demonstration here. The global fallback terrain with EllipsoidTerrainProvider, and configured area with Cesium's default provider at zoom level 13. (red-colored area).

[ggetz]

Thanks @juunie-roh! Your demonstration looks to be working great.

We'll take a closer look at this PR and review shortly. Please let us know if there are any updates to the status of this PR in the meantime.

[juunie-roh]

Hey @ggetz, it's been a while!

I found a way to solve the addressed limitation I stated above. By letting getTileDataAvailable to return true always on defined region, it no longer upsamples the latest available terrain data, delegate the request successfully to the region's provider.

However, I haven't applied it to this PR. Just let me know if you are willing to proceed with this PR.

There is a limitation in the current implementation:

• Cannot override higher zoom levels within configured terrain regions

For example:

• Level 15 region configured with Provider A
• Level 16+ in the same geographic area should use Provider B
• Currently: Level 16+ continues using Provider A

What causes this is:

• Simple region designation cannot change TerrainAvailability.
• Once a region matches, it returns immediately without checking further options.

This could be solved by nesting HybridTerrainProvider instances, but I'm not sure if it's the right direction.

I haven't deeply investigated this limitation yet, as it may be an edge case.