[GRASS-user] Trento3D screenshots redone

Hi,

I have re-done the screenshots of Trento3D (based on
2D building footprint polygons, extruded with v.extrude):

http://grass.itc.it/grass61/screenshots/index.php

Now the correct building heights are used.
Still have to add the 3D trees :slight_smile:

Markus

I have re-done the screenshots of Trento3D (based on
2D building footprint polygons, extruded with v.extrude):

http://grass.itc.it/grass61/screenshots/index.php

Very nice. I learn more every day about GRASS capabilities :slight_smile:

Now the correct building heights are used.
Still have to add the 3D trees :slight_smile:

How would you go about adding 3D objects like trees? Or are you only dreaming?

Tyler

Il giorno gio, 18/05/2006 alle 08.31 -0700, Tyler Mitchell ha scritto:

How would you go about adding 3D objects like trees? Or are you only
dreaming?

http://les-ejk.cz/?cat=grass

Not dreaming... :smiley:

--
Stefano Costa
http://www.iosa.it Software Open Source per l'Archeologia
Jabber: steko@jabber.linux.it
GnuPG Key ID 1024D/0xD0D30245
Linux Registered User #385969 counter.li.org

2006/5/18, Markus Neteler <neteler@itc.it>:

I have re-done the screenshots of Trento3D (based on
2D building footprint polygons, extruded with v.extrude):

Now the correct building heights are used.

Awesome!
--
Paulo Marcondes = PU1/PU2PIX
-22.915 -42.229 = GG87vc (http://www.amsat.org/cgi-bin/gridconv)
Debian GNU/Linux = http://rj.debianbrasil.org = http://www.debian.org

Wonderful…
GRASS and its power, GREAT… tell us the steps taken broadly… if a html for this is there…
GRASS and OSGEO and All the Open GIS developing so fast that
any new entrant finds it climbing a fast escalator going down. some thing has to be done, like a OSGEO group making freelance evaluation or sorts.

Ravi
Markus Neteler neteler@itc.it wrote:

Hi,

I have re-done the screenshots of Trento3D (based on
2D building footprint polygons, extruded with v.extrude):

http://grass.itc.it/grass61/screenshots/index.php

Now the correct building heights are used.
Still have to add the 3D trees :slight_smile:

Markus


grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser


Be a chatter box. Enjoy free PC-to-PC calls with Yahoo! Messenger with Voice.

Stefano Costa wrote:

Il giorno gio, 18/05/2006 alle 08.31 -0700, Tyler Mitchell ha scritto:

How would you go about adding 3D objects like trees? Or are you only
dreaming?

http://les-ejk.cz/?cat=grass

Not dreaming... :smiley:

It's just a matter of having time... Maybe tomorrow,

Markus

On Thursday 18 May 2006 08:45, Stefano Costa wrote:

Il giorno gio, 18/05/2006 alle 08.31 -0700, Tyler Mitchell ha scritto:
> How would you go about adding 3D objects like trees? Or are you only
> dreaming?

http://les-ejk.cz/?cat=grass

Not dreaming... :smiley:

Neat module Jachym !

g.region res=4
r.mapcalc "trees= if(ndvi >= 0.5, 1, null())"
g.region res=8
r.to.vect in=trees out=trees_pts feature=point
g.region res=4
v.trees3d in=trees_pts out=t3d elevation=elev_4m oak=50 pine=50 spruce=0
nviz elev=elev_4m color=ikonos.rgb vect=t3d

output:
http://169.237.35.250/~dylan/temp/pinn_trees.jpg

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

Markus,

Very, very nice! Is there a tutorial on how this is done? If not, is it possible to use the Trento dataset to create one? One possible use — if other details can be worked out — is to create maps of flood inundation to show buildings affected by flooding. I understand one must have the building data (how was *that* obtained?). This type of presentation is very effective in capturing the imagination (as it were) of those possibly affected by flooding.

Regards,
Tom

Markus Neteler wrote:

Hi,

I have re-done the screenshots of Trento3D (based on
2D building footprint polygons, extruded with v.extrude):

http://grass.itc.it/grass61/screenshots/index.php

Now the correct building heights are used.
Still have to add the 3D trees :slight_smile:

Markus

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
  
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

On Thu, May 18, 2006 at 12:57:56PM -0400, Thomas Adams wrote:

Markus,

Very, very nice! Is there a tutorial on how this is done?

That's pretty easy:

- get 2D building polygons with heights as attribute column (v.in.ogr)
- get DEM (r.in.gdal)
- get orthophoto (r.in.gdal)
- interpolate dem to highres (I used 2m pixels) with r.surf.rst
- extrude 2D buildings to 3D (v.extrude, give building heights attribute
  column as option and 2m DEM as elevation)
- start nviz with
  nviz dem2m vect=buildings3d col=orthophoto

that's it!

If not, is it
possible to use the Trento dataset to create one? One possible use ? if
other details can be worked out ? is to create maps of flood inundation
to show buildings affected by flooding.

OK, I couldn't resist :slight_smile:

http://mpa.itc.it/markus/grass61/demos/rlake/
-> see at bottom for new screenshot with flooding
    (needs r.lake which is still not in CVS...)

I understand one must have the
building data (how was *that* obtained?).

The Trento municipality was going out and digitizing all builings.
Another option is to digitize building footprints from orthophoto
(v.digit) and assign a typical height to each building.

If you are lucky, get 3D DXF buildings and import them with
the recently updated v.in.dxf.

This type of presentation is
very effective in capturing the imagination (as it were) of those
possibly affected by flooding.

Fully agreed and done. Except for r.lake everything is in
6.1-CVS.

Only the merge of the flood map with orthophoto could be better
(r.mapcalc will kill the color table, r.patch as well). In February
I did a trick in nviz (see earlier flood screenshots) which I
don't remember today (maybe I loaded the DEM twice or so).

Best,

Markus

Regards,
Tom

Markus Neteler wrote:
>Hi,
>
>I have re-done the screenshots of Trento3D (based on
>2D building footprint polygons, extruded with v.extrude):
>
>http://grass.itc.it/grass61/screenshots/index.php
>
>Now the correct building heights are used.
>Still have to add the 3D trees :slight_smile:
>
>Markus
>
>_______________________________________________
>grassuser mailing list
>grassuser@grass.itc.it
>http://grass.itc.it/mailman/listinfo/grassuser
>

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

> > How would you go about adding 3D objects like trees? Or are you
> > only dreaming?
>
> http://les-ejk.cz/?cat=grass
>
> Not dreaming... :smiley:

Neat module Jachym !

g.region res=4
r.mapcalc "trees= if(ndvi >= 0.5, 1, null())"
g.region res=8
r.to.vect in=trees out=trees_pts feature=point
g.region res=4
v.trees3d in=trees_pts out=t3d elevation=elev_4m oak=50 pine=50 \
spruce=0 nviz elev=elev_4m color=ikonos.rgb vect=t3d

output:
http://169.237.35.250/~dylan/temp/pinn_trees.jpg

I see your trees are in geometric lines. For a more natural looking
picture I would suggest perturbing your vector points (v.perturb) by
a random amount up to about 1/2 of the initial raster resolution.

Hamish

On Thursday 18 May 2006 18:04, Hamish wrote:

> > > How would you go about adding 3D objects like trees? Or are you
> > > only dreaming?
> >
> > http://les-ejk.cz/?cat=grass
> >
> > Not dreaming... :smiley:
>
> Neat module Jachym !
>
> g.region res=4
> r.mapcalc "trees= if(ndvi >= 0.5, 1, null())"
> g.region res=8
> r.to.vect in=trees out=trees_pts feature=point
> g.region res=4
> v.trees3d in=trees_pts out=t3d elevation=elev_4m oak=50 pine=50 \
> spruce=0 nviz elev=elev_4m color=ikonos.rgb vect=t3d
>
> output:
> http://169.237.35.250/~dylan/temp/pinn_trees.jpg

I see your trees are in geometric lines. For a more natural looking
picture I would suggest perturbing your vector points (v.perturb) by
a random amount up to about 1/2 of the initial raster resolution.

Hamish

Hamish:

yet again your sage advice saves the day. Thanks for the tip!

completely forgot about that command...

I'll try it tomorrow and post the results.

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

Let me just say, you guys really inspire me. I have so much GRASS to learn...I mean, enjoy!

:slight_smile:

Tyler

----- Original Message -----
From: Hamish <hamish_nospam@yahoo.com>
Date: Thursday, May 18, 2006 6:04 pm
Subject: Re: [GRASS-user] Trento3D screenshots redone

> > > How would you go about adding 3D objects like trees? Or are you
> > > only dreaming?
> >
> > http://les-ejk.cz/?cat=grass
> >
> > Not dreaming... :smiley:
>
> Neat module Jachym !
>
> g.region res=4
> r.mapcalc "trees= if(ndvi >= 0.5, 1, null())"
> g.region res=8
> r.to.vect in=trees out=trees_pts feature=point
> g.region res=4
> v.trees3d in=trees_pts out=t3d elevation=elev_4m oak=50 pine=50 \
> spruce=0 nviz elev=elev_4m color=ikonos.rgb vect=t3d
>
> output:
> http://169.237.35.250/~dylan/temp/pinn_trees.jpg

I see your trees are in geometric lines. For a more natural looking
picture I would suggest perturbing your vector points (v.perturb)
by
a random amount up to about 1/2 of the initial raster resolution.

Hamish

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

- interpolate dem to highres (I used 2m pixels) with r.surf.rst

is this really needed? g.region res=2 & NVIZ will smooth (or do you see
flat patches/aliasing grid then?).

> If not, is it possible to use the Trento dataset to create one? One
> possible use if other details can be worked out is to create
> maps of flood inundation to show buildings affected by flooding.

Yes! worldwide problem of all coastal & riverside cities. Trillions of
dollars at risk. ([ed.] compare with the cost of dealing with CO2 issues
now) This sort of thing (esp. animated) is very effective for
presenting dry model results to the public & policy makers.

OK, I couldn't resist :slight_smile:

http://mpa.itc.it/markus/grass61/demos/rlake/
-> see at bottom for new screenshot with flooding
    (needs r.lake which is still not in CVS...)

> I understand one must have the
> building data (how was *that* obtained?).

The Trento municipality was going out and digitizing all builings.
Another option is to digitize building footprints from orthophoto
(v.digit) and assign a typical height to each building.

trick: You don't need actual height of buildings, just number of floors.
(how you did Trento version 1 Markus?)
Interns can do orthophoto tracing work :slight_smile: .. LIDAR ..

> This type of presentation is
> very effective in capturing the imagination (as it were) of those
> possibly affected by flooding.

Fully agreed and done. Except for r.lake everything is in
6.1-CVS.

Only the merge of the flood map with orthophoto could be better
(r.mapcalc will kill the color table, r.patch as well). In February
I did a trick in nviz (see earlier flood screenshots) which I
don't remember today (maybe I loaded the DEM twice or so).

Loaded r.lake surface as a second raster?

A trick: in NVIZ make a New constant surface of 0.0, set color to
something white-blue, set transparancy to ~1/2, and raise-lower level
with "Position" button's z-slider. I never seem to get surface order
correct, "Draw Current" is your friend.

e.g. sea level lowered to ice-age/old tectonic levels to show ancient
shore line position:
  http://bambi.otago.ac.nz/hamish/pics/sill_iceage_115m.jpg

Get height from high-water mark of last 100yr flood? (surely recorded)

Hamish

Only the merge of the flood map with orthophoto could be better
(r.mapcalc will kill the color table, r.patch as well).

make single composite color map with r.mapcalc if(r# g# b#) + r.composite?

Hamish

Hamish wrote:

- interpolate dem to highres (I used 2m pixels) with r.surf.rst
   
is this really needed? g.region res=2 & NVIZ will smooth (or do you see
flat patches/aliasing grid then?).

I see stairs - it always depends on how much higher resolution it takes.
Maybe also r.bilinear
does a sufficient good job (and it is fast).

...

I understand one must have the
building data (how was *that* obtained?).
     

The Trento municipality was going out and digitizing all builings.
Another option is to digitize building footprints from orthophoto
(v.digit) and assign a typical height to each building.
   
trick: You don't need actual height of buildings, just number of floors.

... which I don't have (but would like to have...)

(how you did Trento version 1 Markus?)

There was an odd values in the table which I misused. Now, having a
different
data set, I have the measured height.

Interns can do orthophoto tracing work :slight_smile: .. LIDAR ..

Better take stereo photo and "e-photo" software which apparently
recently learned
to extract DEM from stereo images.

BTW: I did it again, now we have buildings colored by their usage (sorry
for the odd
colors):
http://grass.itc.it/grass61/screenshots/index.php

The procedure:
- extract new maps per usage type from original 2D map (v.extract)
- extrude each to 3D (v.extrude, a shell "for" loop is convenient)
- load all maps into NVIZ
- go to color editor for vector lines and change color (here a random
color button
  would be cool)

Cheers

Markus

Hamish & Markus,

How did you do the inundation? With r.lake; does this use a level surface? If so, this is not correct for a river, due to the downstream slope of the topography and the hydrodynamics of the flow. The resulting water surface elevations would be less than a level surface. Channel & overbank cross-sections are needed (corresponding to those used in a dynamic flow model) which then need to be intersected with the topography. The US Army Corps of Engineers HEC-RAS & HEC-GeoRAS software that is integrated with ArcGIS does this correctly.

This is very exciting to see. I am on a National Team within the U.S. NOAA, National Weather Service (NWS) to study and make recommendations on the direction that should be taken with meeting our GIS needs (which is considerable), particularly in the area of operational hydrology, that is, river and flood forecasting. GRASS is **very much** an option. One of the main reasons for the viability of GRASS is that ESRI does not support Linux, which is our operational OS. We operate our computers/models behind a very restrictive firewall. While it is possible to have Windows-based PCs within our operational network (and we do), they are poorly integrated with our Linux-based workflow. Consequently, as far as GIS is concerned, we are somewhat stuck between 2 worlds: Linux & MS-Windows. There are some things ArcGIS can do that we are unable to do in GRASS. My previous paragraph mentions one of them. This is a huge issue for us. So, the more examples I have of GRASS meeting NWS needs, the better.

I have GRASS installed on our operational systems and I use it both interactively for various analyses (mostly involving precipitation & temperature) and in batch mode with some scripts I have written. We have 13 River Forecast Centers and 125 Weather Forecast Office across the US. The possibility exists for GRASS to be used in all these offices and our National Centers. I'm not being boastful here, but through my persistence and "educating" people on GRASS, some River Forecast Centers, one National Center (the Hydometeorological Prediction Center), and the NWS Hydrology Lab. have started using GRASS. This is a big step, because within the NWS, *many* very talented programmers exist who would be itching to contribute to GRASS development if the decision were made to formally adopt GRASS for GIS use. Already, i addition to the use of Linux, the entire NWS recently made the switch to PostgreSQL from INFORMIX. The NWS is fully committed to open source software (there are many using R as well).

Regards,
Tom

Hamish wrote:

- interpolate dem to highres (I used 2m pixels) with r.surf.rst
    
is this really needed? g.region res=2 & NVIZ will smooth (or do you see
flat patches/aliasing grid then?).

If not, is it possible to use the Trento dataset to create one? One
possible use if other details can be worked out is to create
maps of flood inundation to show buildings affected by flooding.
      
Yes! worldwide problem of all coastal & riverside cities. Trillions of
dollars at risk. ([ed.] compare with the cost of dealing with CO2 issues
now) This sort of thing (esp. animated) is very effective for
presenting dry model results to the public & policy makers.

OK, I couldn't resist :slight_smile:

http://mpa.itc.it/markus/grass61/demos/rlake/
-> see at bottom for new screenshot with flooding
    (needs r.lake which is still not in CVS...)

I understand one must have the building data (how was *that* obtained?).
      

The Trento municipality was going out and digitizing all builings.
Another option is to digitize building footprints from orthophoto
(v.digit) and assign a typical height to each building.
    
trick: You don't need actual height of buildings, just number of floors.
(how you did Trento version 1 Markus?)
Interns can do orthophoto tracing work :slight_smile: .. LIDAR ..

This type of presentation is very effective in capturing the imagination (as it were) of those possibly affected by flooding.
      

Fully agreed and done. Except for r.lake everything is in
6.1-CVS.

Only the merge of the flood map with orthophoto could be better
(r.mapcalc will kill the color table, r.patch as well). In February
I did a trick in nviz (see earlier flood screenshots) which I
don't remember today (maybe I loaded the DEM twice or so).
    
Loaded r.lake surface as a second raster?

A trick: in NVIZ make a New constant surface of 0.0, set color to
something white-blue, set transparancy to ~1/2, and raise-lower level
with "Position" button's z-slider. I never seem to get surface order
correct, "Draw Current" is your friend.

e.g. sea level lowered to ice-age/old tectonic levels to show ancient
shore line position:
  http://bambi.otago.ac.nz/hamish/pics/sill_iceage_115m.jpg

Get height from high-water mark of last 100yr flood? (surely recorded)

Hamish
  
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

2006/5/19, Thomas Adams <Thomas.Adams@noaa.gov>:

Hamish & Markus,

How did you do the inundation? With r.lake; does this use a level
surface? If so, this is not correct for a river, due to the downstream
slope of the topography and the hydrodynamics of the flow. The resulting
water surface elevations would be less than a level surface. Channel &
overbank cross-sections are needed (corresponding to those used in a
dynamic flow model) which then need to be intersected with the
topography. The US Army Corps of Engineers HEC-RAS & HEC-GeoRAS software
that is integrated with ArcGIS does this correctly.

Well, that was just to showcase possibilities and then you come with a
class on hidrology!!

Thanks!

I think it should be easy to add a slope to that flood surface, but
that would be still incorrect.
The solution would be to implement a flood modelling routine, but
then, this is the beauty of free software! However, with all my
excitement about all this, I am not the person to implement it... I'm
still lacking some work on the localization of GRASS....

I think I speak for the whole community when I say we are glad to see
GRASS being used is such hi-profile tasks.
--
Paulo Marcondes = PU1/PU2PIX
-22.915 -42.229 = GG87vc (http://www.amsat.org/cgi-bin/gridconv)
Debian GNU/Linux = http://rj.debianbrasil.org = http://www.debian.org

Paulo,

You're right about the need for modeling. Actually, the modeling would be done outside of GRASS and then have the appropriate water surface elevation data imported into GRASS to show the inundated areas. The hydraulic modeling *could* be done withing GRASS, but a better first step probably would be to do the modeling outside of GRASS and then import the data. An additional advantage to this is that there are many hydraulic models and one may have a preference as to which to use or, not be restricted to a particular model, thereby retaining more flexibility.

Tom

pmarc wrote:

2006/5/19, Thomas Adams <Thomas.Adams@noaa.gov>:

Hamish & Markus,

How did you do the inundation? With r.lake; does this use a level
surface? If so, this is not correct for a river, due to the downstream
slope of the topography and the hydrodynamics of the flow. The resulting
water surface elevations would be less than a level surface. Channel &
overbank cross-sections are needed (corresponding to those used in a
dynamic flow model) which then need to be intersected with the
topography. The US Army Corps of Engineers HEC-RAS & HEC-GeoRAS software
that is integrated with ArcGIS does this correctly.

Well, that was just to showcase possibilities and then you come with a
class on hidrology!!

Thanks!

I think it should be easy to add a slope to that flood surface, but
that would be still incorrect.
The solution would be to implement a flood modelling routine, but
then, this is the beauty of free software! However, with all my
excitement about all this, I am not the person to implement it... I'm
still lacking some work on the localization of GRASS....

I think I speak for the whole community when I say we are glad to see
GRASS being used is such hi-profile tasks.

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

Tom,

I didn't intend to make some real hydrological modeling. r.lake
isn't written for that.

In fact, it will be a good idea to connect to external models.
E.g. the SWIG interface could be of help here.

Markus

On Fri, May 19, 2006 at 09:49:41AM -0400, Thomas Adams wrote:

Paulo,

You're right about the need for modeling. Actually, the modeling would
be done outside of GRASS and then have the appropriate water surface
elevation data imported into GRASS to show the inundated areas. The
hydraulic modeling *could* be done withing GRASS, but a better first
step probably would be to do the modeling outside of GRASS and then
import the data. An additional advantage to this is that there are many
hydraulic models and one may have a preference as to which to use or,
not be restricted to a particular model, thereby retaining more flexibility.

Tom

pmarc wrote:
>2006/5/19, Thomas Adams <Thomas.Adams@noaa.gov>:
>>Hamish & Markus,
>>
>>How did you do the inundation? With r.lake; does this use a level
>>surface? If so, this is not correct for a river, due to the downstream
>>slope of the topography and the hydrodynamics of the flow. The resulting
>>water surface elevations would be less than a level surface. Channel &
>>overbank cross-sections are needed (corresponding to those used in a
>>dynamic flow model) which then need to be intersected with the
>>topography. The US Army Corps of Engineers HEC-RAS & HEC-GeoRAS software
>>that is integrated with ArcGIS does this correctly.
>
>Well, that was just to showcase possibilities and then you come with a
>class on hidrology!!
>
>Thanks!
>
>I think it should be easy to add a slope to that flood surface, but
>that would be still incorrect.
>The solution would be to implement a flood modelling routine, but
>then, this is the beauty of free software! However, with all my
>excitement about all this, I am not the person to implement it... I'm
>still lacking some work on the localization of GRASS....
>
>I think I speak for the whole community when I say we are glad to see
>GRASS being used is such hi-profile tasks.

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

Markus,

I understand about the modeling vs r.lake. I guess I just took the opportunity to make the GRASS community aware of the modeling possibilities and the possible direction we may go in the NWS. I really don't know anything about the SWIG interface; can you explain how it could be helpful in this application?

Regards,
Tom

Markus Neteler wrote:

Tom,

I didn't intend to make some real hydrological modeling. r.lake
isn't written for that.

In fact, it will be a good idea to connect to external models.
E.g. the SWIG interface could be of help here.

Markus

On Fri, May 19, 2006 at 09:49:41AM -0400, Thomas Adams wrote:
  

Paulo,

You're right about the need for modeling. Actually, the modeling would be done outside of GRASS and then have the appropriate water surface elevation data imported into GRASS to show the inundated areas. The hydraulic modeling *could* be done withing GRASS, but a better first step probably would be to do the modeling outside of GRASS and then import the data. An additional advantage to this is that there are many hydraulic models and one may have a preference as to which to use or, not be restricted to a particular model, thereby retaining more flexibility.

Tom

pmarc wrote:
    

2006/5/19, Thomas Adams <Thomas.Adams@noaa.gov>:
      

Hamish & Markus,

How did you do the inundation? With r.lake; does this use a level
surface? If so, this is not correct for a river, due to the downstream
slope of the topography and the hydrodynamics of the flow. The resulting
water surface elevations would be less than a level surface. Channel &
overbank cross-sections are needed (corresponding to those used in a
dynamic flow model) which then need to be intersected with the
topography. The US Army Corps of Engineers HEC-RAS & HEC-GeoRAS software
that is integrated with ArcGIS does this correctly.
        

Well, that was just to showcase possibilities and then you come with a
class on hidrology!!

Thanks!

I think it should be easy to add a slope to that flood surface, but
that would be still incorrect.
The solution would be to implement a flood modelling routine, but
then, this is the beauty of free software! However, with all my
excitement about all this, I am not the person to implement it... I'm
still lacking some work on the localization of GRASS....

I think I speak for the whole community when I say we are glad to see
GRASS being used is such hi-profile tasks.
      

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033
    
_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
  
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033