Summary
Legacy rasterio expressions using uppercase two-digit asset names are not translated to rio-tiler bN references.
Reported by Minnie Wong when testing out the v1.0 API for WorldView.
The upgrade to rio-tiler>=9 brought a change to the way bands/assets are expressed in expression statements: all bands were stripped of their names and must be referred to as bX where X is the sequential number of the provided dataset.
Rather than introducing a separate breaking change to force users to use this approach we installed some code to check the input expression for semantic band names and translate it into sequential band names for rio-tiler. Users can also provide the expression using the sequential band names if they prefer.
e.g. these two requests are functionally equivalent:
assets=B11&assets=B12&expression=(B11-B12)/(B11+B12)assets=B11&assets=B12&expression=(b1-b2)/(b1+b2)
where b1 and b2 are the sequential band names for the assets in the order in which they were entered
I think this bug is worth patching for now but we should consider deprecating the expression translation logic and force users to use sequential band names.
Current behavior
A request like:
/rasterio/tiles/...&assets=B11&assets=B12&expression=(B11-B12)/(B11+B12)
returns:
400 {"detail":"Invalid band/asset name 'b11'"}
Expected behavior
(B11-B12)/(B11+B12) should be translated to (b1-b2)/(b1+b2) when assets=B11&assets=B12 are provided.
Cause
CMRAssetsExprParams uses a case-insensitive ^b[1-9][0-9]*$ check when deciding whether an identifier is already a rio-tiler band reference. That incorrectly treats B11 and B12 as already-translated names, so the legacy expression rewrite is skipped.
Acceptance criteria
Summary
Legacy rasterio expressions using uppercase two-digit asset names are not translated to rio-tiler
bNreferences.Reported by Minnie Wong when testing out the v1.0 API for WorldView.
The upgrade to rio-tiler>=9 brought a change to the way bands/assets are expressed in
expressionstatements: all bands were stripped of their names and must be referred to asbXwhereXis the sequential number of the provided dataset.Rather than introducing a separate breaking change to force users to use this approach we installed some code to check the input
expressionfor semantic band names and translate it into sequential band names for rio-tiler. Users can also provide the expression using the sequential band names if they prefer.e.g. these two requests are functionally equivalent:
assets=B11&assets=B12&expression=(B11-B12)/(B11+B12)assets=B11&assets=B12&expression=(b1-b2)/(b1+b2)where
b1andb2are the sequential band names for theassetsin the order in which they were enteredI think this bug is worth patching for now but we should consider deprecating the expression translation logic and force users to use sequential band names.
Current behavior
A request like:
returns:
Expected behavior
(B11-B12)/(B11+B12)should be translated to(b1-b2)/(b1+b2)whenassets=B11&assets=B12are provided.Cause
CMRAssetsExprParamsuses a case-insensitive^b[1-9][0-9]*$check when deciding whether an identifier is already a rio-tiler band reference. That incorrectly treatsB11andB12as already-translated names, so the legacy expression rewrite is skipped.Acceptance criteria
B11andB12are translated correctly in legacy expressions.assets=["B11", "B12"]with expression(B11-B12)/(B11+B12).