Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

min/max statistics not computed at readout for all raster formats #422

Open
jfbourdon opened this issue Jul 29, 2024 · 0 comments
Open

min/max statistics not computed at readout for all raster formats #422

jfbourdon opened this issue Jul 29, 2024 · 0 comments
Assignees
Labels
feature request New feature or request

Comments

@jfbourdon
Copy link
Contributor

Somes hydrology tools automatically evaluate an appropriate flat increment value based on the maximal value stored in the input DEM (see BreachDepressionsLeastCost, BreachDepressions, FillBurn, FillDepressionsPlanchonAndDardoux, FillDepressionsWandAndLiu, FillDepressions, FlowAccumFullWorkflow, UpslopeDepressionStorage). The issue is that this statistic isn't calculate at readout for all file formats but only for Surfer 7, Surfer ASCII, Idrisi, ESRI BIL, Arc Binary and Whitebox (so missing for GeoTiff, Arc ASCII, GRASS and SAGA).

This means that for the later formats, a line like (input.configs.maximum as i32).to_string().len() will output 11 and thus generate a flat increment value of 200 (for a 1 unit cell size) instead of a much smaller and appropriate value.

let small_num = if !flat_increment.is_nan() || flat_increment == 0f64 {
flat_increment
} else {
let elev_digits = (input.configs.maximum as i64).to_string().len();
let elev_multiplier = 10.0_f64.powi((6 - elev_digits) as i32);
1.0_f64 / elev_multiplier as f64 * diagres.ceil()
};

I see two options to fix this:

  1. In each of the aforementioned tools, compute the maximal value instead of relying on what is stored inside the raster config object.
  2. Make computing (and ideally not reading from metadata) min/max statistics for all raster formats. This option has a higher cost, but as other tools might also need those statistics, it avoids having to add lines of code to multiple tools and ensure an application wide fix.
@jblindsay jblindsay self-assigned this Aug 8, 2024
@jblindsay jblindsay added the feature request New feature or request label Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants