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

[Dylan Beaudette]

On Wednesday 28 June 2006 17:24, Helena Mitasova wrote:
> 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?
>

Helena,

Thanks for the overview things:

 I would be very interested in the inclusion of vertical units and datum 
parameters. Does GDAL have any notion of such concepts, and if so can we 
learn from it?

Cheers,


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