[GRASS-user] v.stream.* questions
Reading the manual pages for v.stream.network, v.stream.order, and v.stream.profiler in the extensions doc I see details for the input options but all descriptions refer to raster files. Are there more detailed docs that show examples using the vector modules along with the raster modules? I've a complex, extensive, river network as a vector file. I've not extracted streams, basins, or watersheds from the DEM and I'd like to run the v.stream.* modules on my vector stream network. Possible? TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Basin DEM advice needed [RESOLVED]
On Wed, 2 Oct 2019, Rich Shepard wrote: I assume that I should resample each individual map, then re-run r.patch on the coarser maps because r.slope.aspect and r.info need a single map as input. Would this be an appropriate process? I'm completely open to all suggestions and recommendations. Thanks to advice from several of you I've produced the results I need. I resampled the patched DEM to 5m then generated slope and aspect maps. The basin is so finely dissected (complex river network) that the curvature maps do not communicate useful information. Regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Maps in a defined region
čt 3. 10. 2019 v 15:36 odesílatel Ken Mankoff napsal:
>
> On 2019-10-03 at 15:25 +02, Ondřej Pešek wrote...
> > but r.out.gdal would export "something" from all the maps in the loop,
> > wouldn't it? I thought that if I would loop through all my rasters and
> > pass them to r.out.gdal, it would create an output for every of them,
> > just the ones outside the computational region will be full of no data
> > values. I wanted to avoid this export of empty rasters.
>
> In the loop you cant test each raster for some non-null values:
>
> for r in $(g.list...); do
> eval $(r.univar -g ...)
> if [[ ${sum} != 0 ]]; then...
>
>
Oh, right. That seems like the smoothest solution if there is no
specialized tool. Thanks to all of you.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Maps in a defined region
On 2019-10-03 at 15:25 +02, Ondřej Pešek wrote...
> but r.out.gdal would export "something" from all the maps in the loop,
> wouldn't it? I thought that if I would loop through all my rasters and
> pass them to r.out.gdal, it would create an output for every of them,
> just the ones outside the computational region will be full of no data
> values. I wanted to avoid this export of empty rasters.
In the loop you cant test each raster for some non-null values:
for r in $(g.list...); do
eval $(r.univar -g ...)
if [[ ${sum} != 0 ]]; then...
-k.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Maps in a defined region
čt 3. 10. 2019 v 14:44 odesílatel Markus Neteler napsal: > Ondřej Pešek schrieb am Do., 3. Okt. 2019, 14:41: > >> is there any tool that can output GRASS-imported maps >> > > Do you mean export or display? > > Preferably export. > inside a defined computational region? Raster maps are enough for me, but >> if there is something for all maps, it wouldn't stay unappreciated from my >> side. >> > > Like a loop over all maps, limited to the computational region? r.out.gdal > respects it. > > but r.out.gdal would export "something" from all the maps in the loop, wouldn't it? I thought that if I would loop through all my rasters and pass them to r.out.gdal, it would create an output for every of them, just the ones outside the computational region will be full of no data values. I wanted to avoid this export of empty rasters. čt 3. 10. 2019 v 14:44 odesílatel Rich Shepard napsal: > Have you looked at r.out and v.out? Yes. However, all of them seem to have this behaviour which I would like to avoid (as noted in a response to Markus). ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Maps in a defined region
On Thu, 3 Oct 2019, Ondřej Pešek wrote: is there any tool that can output GRASS-imported maps inside a defined computational region? Raster maps are enough for me, but if there is something for all maps, it wouldn't stay unappreciated from my side. O. Have you looked at r.out and v.out? Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Maps in a defined region
Hi, Ondřej Pešek schrieb am Do., 3. Okt. 2019, 14:41: > Hi, > > is there any tool that can output GRASS-imported maps > Do you mean export or display? inside a defined computational region? Raster maps are enough for me, but > if there is something for all maps, it wouldn't stay unappreciated from my > side. > Like a loop over all maps, limited to the computational region? r.out.gdal respects it. Best Markus Thank you, > O. > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Basin DEM advice needed
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 grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Maps in a defined region
Hi, is there any tool that can output GRASS-imported maps inside a defined computational region? Raster maps are enough for me, but if there is something for all maps, it wouldn't stay unappreciated from my side. Thank you, O. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Basin DEM advice needed
On Thu, 3 Oct 2019, Ken Mankoff wrote: The two maps are showing the same data. d.rast scales each raster to (min,max) of the colorbar, which is why the tiles appear misaligned. The data is unchanged. Ken, And because each individual tile has diffeent minimum and maximum elevations they don't make a smooth surface while the patched map does. Now I understand. I don't see how anyone can answer that without knowing the specifics of your project and goals. To describe geomorphic characteristics of the basin and how they affect channel hydraulics, sediment transport to the lower reaches, and fish distributions, all to a non-technical audience of decision-makers. I'd patch than resample to avoid possible edge effects, if your resample isn't perfectly aligned with each sub-raster. This is what I thought made more sense. Your confirmation is much appreciated. Regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Basin DEM advice needed
Hi Rich A couple of thoughts, below On 03/10/2019 01:22, Rich Shepard wrote: Attached are two maps using 1m LiDAR data. The annotated map, basin-elevations.png, was drawn by individually applying d.rast to each of the 70 maps covering the basin. Sharp breaks can be seen where the data cross quads or flights didn't match up smoothly. 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. The un-annotated map, nehalem-dem-patched.png, displays the results of running r.patch on all 70 maps. Topographically it's quite different from the individual maps; almost flat when the north, east, and south edges should have elevations similar to the other map. I think I should apply r.resamp.stats to aggregate the 1m resolution to 5m. I'd like your thoughts on this. 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. 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. 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. I assume that I should resample each individual map, then re-run r.patch on the coarser maps because r.slope.aspect and r.info need a single map as input. Would this be an appropriate process? I'm completely open to all suggestions and recommendations. 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. Best, Micha Regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Basin DEM advice needed
Hi Rich, On 2019-10-03 at 00:22 +02, Rich Shepard wrote... > Attached are two maps using 1m LiDAR data. The annotated map, > basin-elevations.png, was drawn by individually applying d.rast to each of > the 70 maps covering the basin. Sharp breaks can be seen where the data > cross quads or flights didn't match up smoothly. > > The un-annotated map, nehalem-dem-patched.png, displays the results of > running r.patch on all 70 maps. Topographically it's quite different from > the individual maps; almost flat when the north, east, and south edges > should have elevations similar to the other map. The two maps are showing the same data. d.rast scales each raster to (min,max) of the colorbar, which is why the tiles appear misaligned. The data is unchanged. > I think I should apply r.resamp.stats to aggregate the 1m resolution > to 5m. I'd like your thoughts on this. I don't see how anyone can answer that without knowing the specifics of your project and goals. > I assume that I should resample each individual map, then re-run > r.patch on the coarser maps because r.slope.aspect and r.info need a > single map as input. I'd patch than resample to avoid possible edge effects, if your resample isn't perfectly aligned with each sub-raster. -k. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
