Conversation
|
Do you think it makes sense to merge this PR? Or was this just a draft to help me out? 🙂 |
| **{ | ||
| "id": f"{ix + 1}", | ||
| "scaleDenominator": tr.a * mpu / screen_pixel_size, | ||
| "cellSize": tr.a, |
There was a problem hiding this comment.
Should the cell size always be computed from the horizontal pixel size? How do you handle when there's slight differences between the decimated pixel size in x and y?
In particular, in my implementation I try to assert that the x scale and y scale are the same before I decimate the geotransform.
But with this image https://ds-wheels.s3.us-east-1.amazonaws.com/m_4007307_sw_18_060_20220803.tif, used in the test case I added, that's not always true due to some precision issues:
scaleX, scaleY 2 2
full height, height 12410 6205
full width, width 9680 4840
scaleX, scaleY 4 4.000644745325596
full height, height 12410 3102
full width, width 9680 2420
scaleX, scaleY 8 8.001289490651192
full height, height 12410 1551
full width, width 9680 1210
scaleX, scaleY 16 16.01290322580645
full height, height 12410 775
full width, width 9680 605
scaleX, scaleY 32.05298013245033 32.0671834625323
full height, height 12410 387
full width, width 9680 302
There was a problem hiding this comment.
yeah that's one issue, I don't think TMS can take this into account.
we should at least raise a warning and then select either the smallest or the highest 🤷
Port @vincentsarago 's PR here developmentseed/morecantile#187 to JS for use with geotiff.js. This creates our subset of the TMS spec from a COG image. Note that we diverge from the morecantile PR on ordering: we reverse our ordering of `tileMatrices` to be from coarsest to finest.
cc @kylebarron