Bug in new `calculate_default_transform` from terracotta
See original GitHub issueWhile using the new calculate_default_transform
from Terracotta seemed to help with the performance, I encountered a but when dealing with scene that crosses the dateline separation
The problem happens here: https://github.com/cogeotiff/rio-tiler/blob/06504ec8321d185602a5a91bc6b5415bdb94915c/rio_tiler/utils.py#L232-L241
which will return negative
width/height
Tile
x=17
y=21
z=6
vrt_transfrom
|-386.76, 0.00,-9392582.04|
| 0.00, 6.31, 6887893.49|
| 0.00, 0.00, 1.00|
vrt_width=-1619
vrt_height=-99186
dataset link: https://www.dropbox.com/s/jyskcxqnbq3240c/ask_cog.tif?dl=0
Not sure if it means something but here is the result from both rasterio and terracotta’s calculate_default_transform for a random tile.
# rasterio
| 238.34, 0.00,-20037508.08|
| 0.00,-238.34, 13596067.67|
| 0.00, 0.00, 1.00|
# terracotta
|-386.54, 0.00,-20028306.76|
| 0.00, 6.31, 13596067.67|
| 0.00, 0.00, 1.00|
@dionhaefner, could you test terracotta with the dataset I shared, so I can confirm this is only happening in rio-tiler ?
Issue Analytics
- State:
- Created 4 years ago
- Comments:16 (6 by maintainers)
Top Results From Across the Web
rasterio.warp module - Read the Docs
transform (Affine) – Input affine transformation matrix ... are calculated using GDAL's method for suggest warp output. ... Default is rasterio.enums.
Read more >EhCache POM is misbehaving - java - Stack Overflow
The ehcache versions prior to 2.9.0 have declared terracotta artifacts as a managed dependency supplied by the specific maven repository. A fix for...
Read more >How to use the rasterio.warp.calculate_default_transform ...
To help you get started, we've selected a few rasterio.warp.calculate_default_transform examples, based on popular ways it is used in public projects.
Read more >Possible Bug With Asymmetric Support For Nested Animations ...
I believe there might be a bug in the animation functionality that expresses itself as asymmetric support for nested animations.
Read more >Release Notes for Cisco Prime Collaboration Deployment ...
There are no new features added for this release. Caveats. Bug Search Tool. The system grades known problems (bugs) per severity level.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think I understand the problem now.
It is relatively easy to construct a transform that yields higher quality reprojections than GDAL’s default transform. Just oversample the image a bit to make sure you don’t lose any data.
This changes though when overviews are involved. If you oversample the image, overviews are triggered earlier, leading to an overall degraded quality. You can consider a situation where we duplicate every pixel at the VRT level:
If we then zoom out by a factor of 2, we would ideally see
But by then, the first overview is triggered already! So we actually see something like
As you noticed, trying to force GDAL to use a specific overview is a can of worms that I can’t open at this point.
I suggest the following workaround:
At low zoom levels, this uses the default transform, where it performs reasonably well. At high zoom levels, where we’re at the pixel and sub-pixel level, it makes sure that the VRT always oversamples the tile, so we always get down to the true data density if we zoom far enough.
Comparison
Performance difference is not above noise level.
Yikes, this image is pretty much the perfect storm for my method
In cases like these, we cannot possibly do better than GDAL’s default transform. So even after I fix the bugs and catch these edge-cases, the result will not be better than the default.
I’ll have to come up with a better way to solve this, in the meantime I suggest you revert to the default transform.