[GRASS-user] Basin DEM advice needed

[Rich Shepard]

On Thu, 3 Oct 2019, Micha Silver wrote:

> Can you first zoom in closely to one of the discontinuity areas between
> two tiles and examine the actual values on both sides of the "break". As
> Ken pointed out, it might be just a coloring problem, and NOT really a
> discontinuous step in elevation values.

Micha,

I believe it is a coloring problem where the elevation changes are greatest
because not all tiles show this discontinuity. I was not aware of how
r.colors worked until now.

> I would NOT use resampling to try to overcome discontinuity in the tiles.
> That won't solve the problem, just smear it out a bit. If there really are
> breaks in the data, then (you won't like this...) back to the data
> provider to clarify why there are these breaks in elevation.

No, this makes sense. I've driven through this basin on the two roads (one a
24 mile, unmaintained gravel trail wide enough for a single pickup truck
with a sharp drop to the river on one sied and hills on the other), but that
is not reflected in the digital topography enough to cause a tile-edge
discrepancy. The range of elevations within each tile I now understand would
produce this artifact.

> If the region is too large to keep data at 1 m, then you can decide to
> down-sample to a lower resolution to make the data more manageable.

For this project I don't need such fine resolution but the 10m DEMs I looked
at appeared shfted east by about 100km. Why, I don't know but that's when I
went for the 1m data.

> Also, if there are sliver gaps between the tiles, then you'll want to run
> r.fill.nulls to get these gaps filled by interpolation. In order to save
> time, I suggest to recursively set the region to a very small area
> surrounding each gap, run the r.fill.nulls and patch the filled area back
> into the original. Then move on to the next gap. This will be much faster
> than trying to do r.fill.nulls on the whole region. When finished, don't
> forget to go back to the full region.

Excellent suggestion. That's what I'll do.

> I think the best approach would be creating a VRT, outside of GRASS, using
> the gdalbuildvrt utility: Dump the list of your 70 rasters into a text
> file. Use the -input_file_list parameter to gdalbuildvrt, and you'll have
> one virtual raster for import into GRASS. You can reference it with
> r.external (to avoid importing and duplicating the disk space required).
> Then do whatever hydrological analysis you need with that.

I'll first try looking for sliver spaces and filling those. then resampling
the the patched file to 5m. I've looked at r.buildvrt but not gdalbuildvrt
and this will be what I do if the other approach fails.

Thanks very much.

Regards,

Rich