[GRASS-user] Re: [GRASS-dev] vertical units New module for lake filling - r.lake

[Helena Mitasova]

On Jun 17, 2006, at 5:26 AM, Māris Nartišs wrote:

> Re-posting, as previous mail was larger than lists accept.
>
> Hello all GRASSers.
>
> GRASS CVS contains new module r.lake. This module can be used to  
> create lake
> maps if only place and lake level is known. To use this module You  
> need
> terrain raster map (DEM), water level for lake in same units as DEM  
> values
> and coordinates for any point in lake.
>
> Module uses 3x3 sliding window to fill whole area connected to seed  
> point (can
> be coordinate pair or already existing raster map) and having  
> height values
> below water level. Output map will have lake depth in DEM units. More
> information about module is in help page.
>
> I use this module for palaeolake reconstructions based on single  
> shore line
> measurement. It also can be usefull for reservoir planing, creating  
> maps with
> scenarios for lake level changes etc. Unfortunately mailing lists  
> does not
> accept attachments larger than 100kb - no sample images with r.lake in
> action.
>
> Currently this module has some limitations and I ask for help to  
> other GRASS
> developers to help me to fix them.
> Most important - module is NOT large file safe.
> Lake volume calculations work only if DEM is in meters.
> G_area_of_cell_at_row() always returns cell area in square meters,  
> but I
> could not figure out how to get information about DEM units. Thus  
> if both are
> in meters, volume is correct, else not ...

we have already discussed this in relation to r.slope.aspect which  
has the same problem,
currently it gives warning when x,y in feet is converted to meters so  
that user
can check and make sure that the elevation is in meters too.
There is no place currently in GRASS to store DEM z-units (and  
vertical datum) so it is left to
the user to make sure that the units are handled correctly (big pain  
here in US where
feet and meters are about equally common and mixed in various ways).

I believe that for GRASS7 we should include the vertical datum and  
units information for each location even if we
do not provide the transformation tools - this should help users  
better manage
their elevation and volume data and they can use external tools to  
convert the vertical datum
for the data that they want to import to the datum used in the GRASS  
location.
For example there is an official open source code for US coastal  
vertical datums conversion
available here (it is written in Java2 though)

http://chartmaker.ncd.noaa.gov/csdl/vdatum.htm

This would not prevent the users to mix misc. vert. and horiz. datums  
and units in their database
(at their own peril as I have learned the hard way), but it will  
encourage the management
of data in a well defined coordinate system and units in all 3  
dimensions.

Helena

P.S. I would like to add this suggestion to the wiki development page  
- apparently it should go
under Plans but it does not fit into Overview, should I add it to  
sand box?
Or should we start a GRASS7 proposals/suggestions/todo section?




>
> Thanks to all who helped me to code this module.
>
> Any comments, ideas, enhancements - always welcome.
>
> Maris Nartiss.
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev