mike-000

@sunilkpai #15077 might be a good starting point but it is ignoring the view projection's world extent. For an EPSG:4326 graticule the graticule projection world extent covers the whole world,...

It looks like those files only contain nodata settings for the first 4 bands. The next 6 bands also use -9999 but the 11th band is like an inverse alpha...

The data is being rendered in the wrong position (or perhaps the tilegrid extent is wrong), and with `wrapX: false` limiting the output to the tilegrid extent you will not...

This is probably due to https://github.com/geotiffjs/geotiff.js/pull/361 If I use the build from #15402 which uses the original bounding box algorithm it renders inside the tilegrid extent https://jsfiddle.net/17az2dmb/ although your proj4...

The proj4 definition is correct, it looks like the ModelTransformation must be always be applied, as it can flip the tilegrid as well as rotate or skew it https://jsfiddle.net/fcb4nrtm/

You had a normal top left origin with a ModelTransformation flipping the grid. I have updated #15402 to handle this as well as rotation or skew specified by ModelTransformation.

Ready for review as I do not have any files small enough to use for a rotated or skewed rendering test, although the test file from #15428 would be suitable....

@loganwilliams There is a large selection of open data available via https://radiantearth.github.io/stac-browser/#/external/s3.us-west-2.amazonaws.com/umbra-open-data-catalog/stac/catalog.json typically around that size suitable for use in examples but too big to use as local test data....

@ahocevar This is ready for further review. Workarounds have been removed in favour of the latest geotiff.js methods. The handling of matrixes in projections now uses entire transform functions (in...

Separating matrix and projection transforms has the potential for double reprojection. I would regard the image as being in a rotated version of a standard projection - in the example...