nasa / harmony-browse-image-generator

Other
1 stars 3 forks source link

DAS-2115: Change how the default scale_extent is computed #9

Closed flamingbear closed 2 months ago

flamingbear commented 2 months ago

Description

This PR fundamentally changes how the default scale extent is computed.

It is now based entirely on the reprojected bounding box of the input granule.

An input image that shares its CRS with the target CRS will have no changes to the extent of the input image. An input image that had a different CRS to the target CRS will trasform the input box into the target CRS using rioxarray's transform_bounds. Which densifies each edge of the bounding rectangle before reprojection to keep a correct target CRS bounding box.

Jira Issue ID

DAS-2118

Local Test Steps

Build and run the tests.

❯ ./bin/build-image && ./bin/build-test && ./bin/run-test

Ensure everything passes.

Run this test request against a working Harmony-In-A-Box (build from repo branch: HARMONY-1766-numerical-parameters-in-POST):

http://localhost:3000/C1256584478-EEDTEST/ogc-api-coverages/1.0.0/collections/all/coverage/rangeset?forceAsync=true&outputcrs=EPSG%3A4326&granuleId=G1256584570-EEDTEST&format=image%2Fpng

It should pass and the output png image should have the same corner points as the raw input file [since there is no translation because the input crs == output crs]

...
    ID["EPSG",4326]]
Data axis to CRS axis mapping: 2,1
Origin = (21.999861111111102,1.000138888888890)
Pixel Size = (0.000274650680334,-0.000274650680334)
Corner Coordinates:
Upper Left  (  21.9998611,   1.0001389) ( 21d59'59.50"E,  1d 0' 0.50"N)
Lower Left  (  21.9998611,  -0.0001389) ( 21d59'59.50"E,  0d 0' 0.50"S)
Upper Right (  23.0001389,   1.0001389) ( 23d 0' 0.50"E,  1d 0' 0.50"N)
Lower Right (  23.0001389,  -0.0001389) ( 23d 0' 0.50"E,  0d 0' 0.50"S)
Center      (  22.5000000,   0.5000000) ( 22d30' 0.00"E,  0d30' 0.00"N)

Next make the same request but ask for it on the EASE Grid-2 Global projection EPGS:6933

http://localhost:3000/C1256584478-EEDTEST/ogc-api-coverages/1.0.0/collections/all/coverage/rangeset?forceAsync=true&outputcrs=EPSG%3A6933&granuleId=G1256584570-EEDTEST&format=image%2Fpng

You should also see an image that is bound to the input images size but has the correct metadata

    ID["EPSG",6933]]
Data axis to CRS axis mapping: 1,2
Origin = (2122684.764647465664893,127584.701180988311535)
Pixel Size = (32.000358751793740,-31.996594707446629)
Corner Coordinates:
Upper Left  ( 2122684.765,  127584.701) ( 21d59'59.50"E,  1d 0' 0.50"N)
Lower Left  ( 2122684.765,     -17.719) ( 21d59'59.50"E,  0d 0' 0.50"S)
Upper Right ( 2219197.847,  127584.701) ( 23d 0' 0.50"E,  1d 0' 0.50"N)
Lower Right ( 2219197.847,     -17.719) ( 23d 0' 0.50"E,  0d 0' 0.50"S)
Center      ( 2170941.306,   63783.491) ( 22d30' 0.00"E,  0d29'59.93"N)

You should be able to open the orignal tif, the EPSG:4326 or EPSG:6933 png flies in QGIS and see they overlap each other exactly.

PR Acceptance Checklist

owenlittlejohns commented 2 months ago

Also should have mentioned - I ran the example requests listed in the PR description, and the results look as expected in gdalinfo (also they loaded correctly in QGIS, and were correctly geolocated with respect to an OpenStreetMap layer). Nice!