Opened 11 years ago
Last modified 9 years ago
#2018 new enhancement
Provide a way to edit the PERMANENT/MYNAME file
Reported by: | Nikos Alexandris | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 6.4.6 |
Component: | Default | Version: | unspecified |
Keywords: | location, description, ps.map | Cc: | |
CPU: | Unspecified | Platform: | Unspecified |
Description
Besides _editing_ the PERMANENT/MYNAME file manually (later, not while creating a Location), is there a "proper" way to do so? It is used for example by the "header" instruction in ps.map.
I can't trace a single reference about it in any of the user-manuals except for in ps.map's section about the header instruction <http://grass.osgeo.org/grass64/manuals/ps.map.html#header>:
%L - Location's text description
And, of course, in the Programmer's manual, i.e. in <http://grass.osgeo.org/programming7/myname_8c.html>.
Maybe add an option to "g.proj" or an(other) environment variable "LOCATION_DESCRIPTION" to be set with "g.gisenv"?
Change History (5)
comment:1 by , 11 years ago
follow-up: 3 comment:2 by , 11 years ago
try new -n and descr= options in g.setproj with r56961 in devbr6.
Not sure about in grass7, I feel g.proj is already a bit overloaded wrt functionality, but it's not enough for its own g.support module.
any ideas?
Hamish
comment:3 by , 11 years ago
Replying to hamish:
try new -n and descr= options in g.setproj with r56961 in devbr6.
Works :-)
Not sure about in grass7, I feel g.proj is already a bit overloaded wrt functionality, but it's not enough for its own g.support module.
any ideas?
The ones who know the internals very well have a better idea on that. Would it be really too much to add the "description=" to g.proj in G7?
comment:5 by , 9 years ago
Milestone: | 6.4.4 → 6.4.6 |
---|
Currently it's settable at the time that you create the location, after that you need to edit the text file by hand.
in grass6 I'd add editing it as an option to g.setproj, not g.proj. Code should be very similar to several r.support options. Not sure about in grass7, I feel g.proj is already a bit overloaded wrt functionality, but it's not enough for its own g.support module.
it's generally set-and-forget, so doesn't belong in g.gisenv as a variable.
Hamish