Skip to content

Feature/add from rasterio cli#187

Draft
vincentsarago wants to merge 2 commits intomainfrom
feature/add-from-rasterio-cli
Draft

Feature/add from rasterio cli#187
vincentsarago wants to merge 2 commits intomainfrom
feature/add-from-rasterio-cli

Conversation

@vincentsarago
Copy link
Member

morecantile from-rasterio world.tif | jq 
{
  "title": "file.tif",
  "id": "2db20044-2896-46e4-b146-37b0a6643953",
  "crs": "http://www.opengis.net/def/crs/EPSG/0/4326",
  "boundingBox": {
    "lowerLeft": [
      -179.8333333333333,
      -89.8333333333693
    ],
    "upperRight": [
      179.8333333334053,
      89.83333333333331
    ],
    "crs": "http://www.opengis.net/def/crs/EPSG/0/4326"
  },
  "tileMatrices": [
    {
      "id": "0",
      "scaleDenominator": 6626160.166267611,
      "cellSize": 0.01666666666667,
      "cornerOfOrigin": "topLeft",
      "pointOfOrigin": [
        -179.8333333333333,
        89.83333333333331
      ],
      "tileWidth": 128,
      "tileHeight": 128,
      "matrixWidth": 169,
      "matrixHeight": 85
    }
  ]
}

cc @kylebarron

@kylebarron
Copy link
Member

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,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🤷

kylebarron added a commit to developmentseed/deck.gl-raster that referenced this pull request Dec 16, 2025
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants