Re: [GRASS-user] r.damflood question

[Moritz Lennert]

Le Mon, 28 Aug 2017 17:05:01 -0400,
Anna Petrášová  a écrit :

> Hi,
> 
> On Mon, Aug 28, 2017 at 4:53 PM, Codrina Maria Ilie
>  wrote:
> > Hi all,
> >
> > I have been trying to run GRASS7 module r.damflood using the
> > following datasets
> > [https://drive.google.com/drive/folders/0B2Yx_1shUSx3VThlY3BrV1JyWjg?usp=sharing],
> > with this command:
> >
> > r.damflood --overwrite --verbose elev=dem lake=water_depth
> > dambreak=dam_breach manning=manning tstop=3 deltat=1 h=b_depth
> > vel=b_vel hmax=b_mwd vmax=b_mwv imax=b_mi wavefront=b_wf
> >
> > To make it easier, the lake has a constant depth.
> >
> > As far as I can understand, the rasters should be correctly built,
> > but the outputs of r.damflood are obviously wrong (rasters with
> > nodata or one category = 0; at second 1 the depth raster is half
> > the lake's size (s00.png, s01.png)and at second 2, it completely
> > disappears).
> >
> > During the processing, I get the Courant-Friedrich-Lewy stability
> > condition warning message.
> >
> > If I try to chose as computational method for initial velocity
> > estimation, uniform drop in of lake or small dam breach, I get the
> > following error "ERROR: Don't find the dambreak - Please select a
> > correct map or adjust the computational region".
> >
> > Does anyone have an idea what could be the reason of these results,
> > please? Any suggestion would be highly appreciated.  
> 
> Your water_depth should have 0 instead of nulls, I think that's the
> problem in your case. The stability condition warning probably means
> you should reduce your time step, on the other hand, it will take more
> time.
> 

r.null null=0 gets rid of the stability condition warning as well.

However, I don't know much about this module, but I'm a bit surprised
by your DEM: IIUC, it's level is lower in the entire dam lake area than
in the valley below. Also: is it normal that your water depth is
constant all over the lake ?

Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.damflood question

[Anna Petrášová]

Hi,

On Mon, Aug 28, 2017 at 4:53 PM, Codrina Maria Ilie
 wrote:
> Hi all,
>
> I have been trying to run GRASS7 module r.damflood using the following
> datasets
> [https://drive.google.com/drive/folders/0B2Yx_1shUSx3VThlY3BrV1JyWjg?usp=sharing],
> with this command:
>
> r.damflood --overwrite --verbose elev=dem lake=water_depth
> dambreak=dam_breach manning=manning tstop=3 deltat=1 h=b_depth vel=b_vel
> hmax=b_mwd vmax=b_mwv imax=b_mi wavefront=b_wf
>
> To make it easier, the lake has a constant depth.
>
> As far as I can understand, the rasters should be correctly built, but the
> outputs of r.damflood are obviously wrong (rasters with nodata or one
> category = 0; at second 1 the depth raster is half the lake's size (s00.png,
> s01.png)and at second 2, it completely disappears).
>
> During the processing, I get the Courant-Friedrich-Lewy stability condition
> warning message.
>
> If I try to chose as computational method for initial velocity estimation,
> uniform drop in of lake or small dam breach, I get the following error
> "ERROR: Don't find the dambreak - Please select a correct map or adjust the
> computational region".
>
> Does anyone have an idea what could be the reason of these results, please?
> Any suggestion would be highly appreciated.

Your water_depth should have 0 instead of nulls, I think that's the
problem in your case. The stability condition warning probably means
you should reduce your time step, on the other hand, it will take more
time.

Anna

>
> Cheers,
> Codrina
>
>
>
>
>
>
> ___
> 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

[GRASS-user] r.damflood question

[Codrina Maria Ilie]

Hi all,

I have been trying to run GRASS7 module r.damflood using the following 
datasets 
[https://drive.google.com/drive/folders/0B2Yx_1shUSx3VThlY3BrV1JyWjg?usp=sharing], 
with this command:


r.damflood --overwrite --verbose elev=dem lake=water_depth 
dambreak=dam_breach manning=manning tstop=3 deltat=1 h=b_depth vel=b_vel 
hmax=b_mwd vmax=b_mwv imax=b_mi wavefront=b_wf


To make it easier, the lake has a constant depth.

As far as I can understand, the rasters should be correctly built, but 
the outputs of r.damflood are obviously wrong (rasters with nodata or 
one category = 0; at second 1 the depth raster is half the lake's size 
(s00.png, s01.png)and at second 2, it completely disappears).


During the processing, I get the Courant-Friedrich-Lewy stability 
condition warning message.


If I try to chose as computational method for initial velocity 
estimation, uniform drop in of lake or small dam breach, I get the 
following error "ERROR: Don't find the dambreak - Please select a 
correct map or adjust the computational region".


Does anyone have an idea what could be the reason of these results, 
please? Any suggestion would be highly appreciated.


Cheers,
Codrina






___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re-projected Data Position Mismatch

[Jeshua Lacock]

> On Aug 27, 2017, at 8:54 PM, Anna Petrášová  wrote:
> 
> On Tue, Aug 22, 2017 at 7:46 PM, Jeshua Lacock  wrote:
>> 
>> To hopefully help troubleshoot; I just reprojected one of the raster tiles 
>> (from epsg: 3857), into the source location of one of the lonlat vectors 
>> (reverse projections from my OP), and the datasets are offset by the same 
>> distances. Since the dimensions of the raster are being changed (by r.proj), 
>> it leads me to think it must be a datum or coordinate system misalignment 
>> and not a projection issue.
> 
> I have the same problem, working with NAIP imagery. It is related to:
> https://trac.osgeo.org/grass/ticket/2229
> 
> I have to remove nadgrids: @null from the PROJ_INFO file to be able to
> reproject into that location, but then it is shifted. gdalwarp helps.

Hi Anna!

Thank you very much for confirming that! I am working with the NAIP imagery as 
well.  :)

I have found that their original Geotiff assets work perfectly.

In fact, I was very happy to stumble on to the fact that the complete NAIP 
archive (~250 terabytes) is available as a bucket drive on Amazon Web Services 
(AWS). So I setup GRASS instances to process the tiles, then download the 
processed, reprojected images compressed as JP2s. I am paying for the bandwidth 
and compute time, but I think its worth it for my purposes. I’ll be able to 
process and download the imagery I need in about 60 days compared to over 300 
days without AWS!


Cheers,

Jeshua Lacock
Founder/Engineer
<3DTOPO.com>
GlassPrinted.com

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user