Your Environment
- Version used: revision 56f189d
- Browser: Chrome & Firefox
- Operating System: Ubuntu
Context
A globe view stops refining correctly when the elevation layer is configured with a minimum zoom. Only a few coarse tiles appear, deeper levels do not load, and camera interactions become unreliable because picking has almost no refined ground to work with.
During the regression, the console repeatedly shows subdivision-blocked for the low-resolution elevation layer, that layer stays at tileLevel: -1, and a later frame update can end with "Uncaught TypeError: coordinates must be finite numbers".
Steps to Reproduce
- In the view_3d_map.html example, right after
config.source = new itowns.WMTSSource(config.source); and before view.addLayer(new itowns.ElevationLayer(..., add config.zoom = { min: 11 };.
- Load the example and zoom in on the globe. The tiles don't refine.
Expected Behavior
The globe should keep refining normally. An elevation layer with zoom.min should simply start providing data from its configured minimum zoom without blocking root-level globe subdivision.
Actual Behavior
Globe subdivision stalls at very low resolution. Refinement stays blocked on the elevation layer, deeper tiles do not load, and navigation and picking quality degrade sharply.
Possible Cause/Fix/Solution
The regression was introduced by commit 3c64961 on master, titled "refacto(Source): refactor extentInsideLimit() to hasData()".
This looks like a regression in the interaction between globe subdivision and elevation-layer availability checks. If an elevation layer declares coverage but cannot fetch data yet because of zoom.min, root nodes appear to wait indefinitely for elevation data instead of continuing refinement until the layer becomes eligible.
Your Environment
Context
A globe view stops refining correctly when the elevation layer is configured with a minimum zoom. Only a few coarse tiles appear, deeper levels do not load, and camera interactions become unreliable because picking has almost no refined ground to work with.
During the regression, the console repeatedly shows subdivision-blocked for the low-resolution elevation layer, that layer stays at
tileLevel: -1, and a later frame update can end with "Uncaught TypeError: coordinates must be finite numbers".Steps to Reproduce
config.source = new itowns.WMTSSource(config.source);and beforeview.addLayer(new itowns.ElevationLayer(..., addconfig.zoom = { min: 11 };.Expected Behavior
The globe should keep refining normally. An elevation layer with zoom.min should simply start providing data from its configured minimum zoom without blocking root-level globe subdivision.
Actual Behavior
Globe subdivision stalls at very low resolution. Refinement stays blocked on the elevation layer, deeper tiles do not load, and navigation and picking quality degrade sharply.
Possible Cause/Fix/Solution
The regression was introduced by commit 3c64961 on master, titled "refacto(Source): refactor extentInsideLimit() to hasData()".
This looks like a regression in the interaction between globe subdivision and elevation-layer availability checks. If an elevation layer declares coverage but cannot fetch data yet because of zoom.min, root nodes appear to wait indefinitely for elevation data instead of continuing refinement until the layer becomes eligible.