#2332: change r.horizon output names from "angle index" to "angle"
-------------------------+--------------------------------------------------
Reporter: zarch | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.1.0
Component: Default | Version: svn-trunk
Keywords: | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
At the moment r.horizon combine the prefix with the angle index.
I think that use the angle degree instead of the angle index, could be
clearer and easier to interpret the raster name. Moreover using the angler
can help to avoid situations, like: imagine that you generate all the map
using a horizon step of 10 degrees,
{{{
$ r.horizon elev_in=elevation horizon=h_ hrorizon_step=10
}}}
now suppose that, after some testing you want to use a step of 5 degrees,
with the current approach user have to run setting horizon_step to 5...
Recomputing half of the already existing maps.
If the parameters horizon_start and horizon_end will be accepted
user can just compute the missing raster maps with:
{{{
$ r.horizon elev_in=elevation horizon=h_ hrorizon_step=10 horizon_start=5
}}}
And here raise the name problem, using the angle index convention we are
going to overwrite all the previous raster map, so user should change the
horizon parameters like:
{{{
$ r.horizon elev_in=elevation horizon=h2_ hrorizon_step=10 horizon_start=5
}}}
And then write a script to "merge" the outputs renaming the raster maps
accordingly with index convention. If we change from the angle index to
the angle we solve the name conflicts, generating (h0, h5, h10, etc)
instead of (h0, h1, h3, etc).
Change from the angle index (integer) to the angle (double) we have to
manage some how the decimals. I see two main options:
1. add an extra parameter with the number of decimals to use in the format
name.
{{{
$ r.horizon elev_in=elevation horizon=h_ hrorizon_step=0.5 horizon_end=2
decimals=1
}}}
It will generate: h_0.0, h_0.5, h_1.0, h_1.5
2. change the horizon parameter from raster prefix to the format string,
so the command will be:
{{{
$ r.horizon elev_in=elevation horizon=h_%4.1f hrorizon_step=0.5
horizon_end=2
}}}
It will generate: h_0.0, h_0.5, h_1.0, h_1.5
On the other hand change the r.horizon convention it means that we are
going to break others modules that are using r.horizon output maps as
input such as r.sun, r.sky view, etc. but should not too dificult to fix.
What do you think?
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2332>
GRASS GIS <http://grass.osgeo.org>