Identify filled pits

[sgrieve]

There are a bunch of ways to flag up filled pits, but I think the most parsimonious solution is to diff the original and filled rasters and anywhere there is a difference, we can flag as a pit filled area.

The subsequent challenge is what we do when a channel encounters a pit?

Options:

• Do nothing in LSD and flag them with a later process, allowing us to remove channels that hit pits (or too many pits)
• Convert the flagged areas to NDV, ending channels as soon as they hit a pit
  • This may create a discontinuous network/screw up topology. Or perhaps it is screwed up more by the pits being routed over?
• Add a flag to the output of the results so pit channel pixels can be skipped, creating a discontinuous network of channel pixels that we are confident about (but anything downstream of a big flat area may be garbage due to the straight routing across the surface)

[sgrieve]

A tweak to the NDV conversion option would be to allow small pits (1-4 px) and exclude anything bigger.

If we do the NDV route should we remove any orphan channels that do not flow into anything and have no tributaries?

[sgrieve]

I have overloaded the fill method to track the row and col indices of filled pits within a dem (b4f9ea9). This allows us to match up the individual channel pixels (who also have row, col recorded) to the list of filled pixels. We can the identify channels that intersect with too man modified pixels and exclude them after the main HPC run. I will do this alongside the flowdir searches and it will all be done in python as a postprocessing step.

This will allow us to modify thresholds without having to re-run the whole analysis.

[sgrieve]

We now have working pit flagging that has been propagated through all of the processing steps, and tested successfully on the full dataset.

We are currently flagging all pixels that have an elevation change beyond the 98th percentile of changes across the whole DEM. Another option would be to set this threshold statically based on the reported error bounds within SRTM data. This can be easily achieved with a change to the c++ driver code.