[GRASS-dev] ascii export and import, large file problem

[Helena Mitasova]

Hamish,

can you please add your suggestion for adding cell_misc/units to
an appropriate place (development) on wiki so that it does not get  
burried
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,  
precipitation
map can be mm/month or mm/hr, inputs or outputs such as  infiltration  
rate,
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 -  
we forgot
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).

Thanks, Helena


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--
>>> [1...]
>>> 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.
>>
>>> [2...]
>>>> 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.
>>> --endquote--
>>
>> 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
>> interpretation.
>>
>> I'm really not too sure.
>
>
> ok, proposal:
>
> add raster map specific cell_misc/units and cell_misc/vertical_datum
> files.
>
> 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  
> helpful
> we need to allow a custom entries. I'm not too sure about them though.
>
>
> Hamish