You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using the TerrainLayer, the elevationData parameter can accept either an image or a URL for a tile service, typically using the {z}/{x}/{y} format. However, when using a TMS-style tile service (where the Y coordinate is flipped or negative), the TerrainLayer fails to render the elevation data correctly because it misinterprets the URL as an image rather than a tile service.
I investigated the code and found that in the file modules/geo-layers/src/terrain-layer/terrain-layer.ts, there is a condition that determines whether the elevationData source is treated as a tile service or as an image. The condition is as follows:
Since the condition checks for the {y} placeholder in the string, it does not recognize TMS-style URLs where the Y coordinate is negative (e.g., using {-y}), and as a result, it interprets the source as an image instead of a tile service.
Solution
If we update the condition to also check for {-y}, the TerrainLayer will correctly handle TMS-style tile services. By modifying the condition as follows:
The TerrainLayer should correctly interpret the TMS-style URLs, recognizing {-y} as a valid coordinate format, and render the elevation data properly from the tile service.
Steps to Reproduce
To reproduce the bug, simply use any TMS-style tile service (where the Y coordinate is flipped or negative) as elevationData for a TerrainLayer.
Environment
Framework version: 9.1.0-alpha.0
Browser: Chrome Version 129.0.6668.60
OS: macOS Sequoia Version 15.1 Beta
Logs
No response
The text was updated successfully, but these errors were encountered:
I hope you’re all doing well! I wanted to kindly follow up on a bug report I submitted a few months ago. I understand that everyone is juggling multiple priorities, but I just wanted to check in and see if there might be any updates or if there’s anything I could do on my end to help facilitate a resolution. This issue has been affecting our project’s workflow, so any information you could share would be greatly appreciated.
Thank you very much for your time and for all the hard work you’re putting into improving the platform. Looking forward to hearing from you!
Description
When using the
TerrainLayer
, theelevationData
parameter can accept either an image or a URL for a tile service, typically using the{z}/{x}/{y}
format. However, when using a TMS-style tile service (where the Y coordinate is flipped or negative), theTerrainLayer
fails to render the elevation data correctly because it misinterprets the URL as an image rather than a tile service.I investigated the code and found that in the file
modules/geo-layers/src/terrain-layer/terrain-layer.ts
, there is a condition that determines whether theelevationData
source is treated as a tile service or as an image. The condition is as follows:Since the condition checks for the
{y}
placeholder in the string, it does not recognize TMS-style URLs where the Y coordinate is negative (e.g., using{-y}
), and as a result, it interprets the source as an image instead of a tile service.Solution
If we update the condition to also check for
{-y}
, the TerrainLayer will correctly handle TMS-style tile services. By modifying the condition as follows:everything works as expected.
I've cloned the repository and tested it; I can confirm that the following patch works:
Flavors
Expected Behavior
The
TerrainLayer
should correctly interpret the TMS-style URLs, recognizing{-y}
as a valid coordinate format, and render the elevation data properly from the tile service.Steps to Reproduce
To reproduce the bug, simply use any TMS-style tile service (where the Y coordinate is flipped or negative) as
elevationData
for aTerrainLayer
.Environment
Logs
No response
The text was updated successfully, but these errors were encountered: