Depending on the system, simply running generate_fmask_outputs as-is can easily cause memory errors.
This is because we hold onto a lot of information that we don't necessarily need to so that we can write out geoTIFFs for ancillary data series.
A better approach might be to construct Landsat8Scene in a builder pattern. So FMask has a method that provides a graph of strings detailing, for a given data series, the dependency graph on how to calculate it. Then Landsat8Scene can use that graph to minimize how much stuff it's actually keeping in memory.
Currently Landsat8Scene usage is like, "Here's raw data. Clean it, then process it, then generate all the new fmask data. Now give me this series."
The new usage for Landsat8Scene would be more like, "Here's raw data, and here's the specific data series (plural) I need. Figure out how to put it together for me."
Depending on the system, simply running
generate_fmask_outputsas-is can easily cause memory errors.This is because we hold onto a lot of information that we don't necessarily need to so that we can write out geoTIFFs for ancillary data series.
A better approach might be to construct Landsat8Scene in a builder pattern. So FMask has a method that provides a graph of strings detailing, for a given data series, the dependency graph on how to calculate it. Then Landsat8Scene can use that graph to minimize how much stuff it's actually keeping in memory.
Currently Landsat8Scene usage is like, "Here's raw data. Clean it, then process it, then generate all the new fmask data. Now give me this series."
The new usage for Landsat8Scene would be more like, "Here's raw data, and here's the specific data series (plural) I need. Figure out how to put it together for me."