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
_______________________________________________
grass-user mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-user

Reply via email to