[GRASS-dev] ascii export and import, large file problem
hmitaso at unity.ncsu.edu
Wed Apr 25 23:42:03 EDT 2007
can you please add your suggestion for adding cell_misc/units to
an appropriate place (development) on wiki so that it does not get
in the mail archives?
I am finding the unit info essential especially for modeling (I
started to add
it to the file names for lack of other options) - for example,
map can be mm/month or mm/hr, inputs or outputs such as infiltration
erodibility, critical sheer stress, all can have different units,
you can have temperature in deg Celsius or Fahrenheit
- there are many examples. Also the modules should be able
to check the unit (e.g. r.slope.aspect for feet or meters) and/or at
least inform the user
in the --help what units are expected (I am just adding it to simwe -
to describe it in manual and there was no way to find out that
e.g. rainfall was expected in m/s rather than more common mm/hr).
On Apr 20, 2007, at 3:28 AM, Hamish wrote:
> Paul Kelly wrote:
>> Hello Hamish
>> Thanks for bringing this up again. ISTR being too busy to reply
>> straight away the last time and then forgetting...
>> On Wed, 18 Apr 2007, Hamish wrote:
>>> --relevant quotes--
>>> For a real y-axis label I think we need to add a new (optional)
>>> "units" element to the raster format (e.g. in cell_misc/).
>> OK this seems like a very good idea. Several times Helena has
>> suggested the idea of adding "vertical datum" support to a location,
>> but I was always quite negative about it in pointing out that there
>> was not even any way of indicating that a particular raster map
>> contained elevation data. But in fact, the obvious answer seems now
>> to be that it should be done on a per-raster map basis rather than a
>> per-location basis. I.e. if the metadata for a raster map indicates
>> that it contains elevation data (i.e. units are a length measure)
>> then there should also be a facility to specify the vertical datum
>> the length measure is relative to.
>>>> The user should be able to add a title for the legend.
>>> For vlegends that's doable. For raster legends I hope to add
>>> G_set_raster_units() and G_get_raster_units() to write/read a simple
>>> string containing raster data units (set from "r.support units=")
>>> which will be stored in $MAPSET/cell_misc/$RASTERMAP/units. Raster
>>> legends and things like lat/lon NVIZ and r.shaded.relief could use
>>> the tag if it existed.
>> I think it's worth putting enough thought in so that the feature is
>> easily usable for more than just legend titles. Especially how to
>> specify vertical datums. I suppose there are a few very standard
>> ones, like WGS84 ellipsoidal height and that kind of thing. Actually
>> I think the EPSG co-ordinate system database also includes vertical
>> datums. Maybe it has some kind of unique codes that we could re-use.
>> Maybe we should have a vdatum.table file with descriptions. Or maybe
>> we should just put a human-readable name in and leave it for manual
>> I'm really not too sure.
> ok, proposal:
> add raster map specific cell_misc/units and cell_misc/vertical_datum
> Each would hold a single line string containing the info.
> You could set the value with e.g. "r.support units="
> You could query with e.g. "r.info -u"
> read/write using new cell_misc libgis fns described by Glynn in an
> earlier email.
> both fully optional, and non-existing by default, so fully backwards
> compatible with old maps.
> for use by modules, just start with strcmp(tolower(*string), "meters")
> for hinting. units can be anything, so I prefer to allow freeform
> metadata there, not just something from a list. I fear that vertical
> datums may use very local names so while a common table would be
> we need to allow a custom entries. I'm not too sure about them though.
More information about the grass-dev