[GRASS-dev] [GRASS GIS] #1635: allow r.los to run with a point vector layer as input for "coordinate identifying the viewing position"
GRASS GIS
trac at osgeo.org
Sun Jan 12 15:56:00 PST 2014
#1635: allow r.los to run with a point vector layer as input for "coordinate
identifying the viewing position"
---------------------------------------+------------------------------------
Reporter: lutra | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: minor | Milestone: 6.4.5
Component: Raster | Version: svn-releasebranch64
Keywords: r.los, r.lake, r.viewshed | Platform: All
Cpu: All |
---------------------------------------+------------------------------------
Changes (by wenzeslaus):
* keywords: r.los, r.lake => r.los, r.lake, r.viewshed
Comment:
In r58688, I changed `xy` to standard `coordinates` option which enables
to interactively pick coordinates from map display if you start G7:r.lake
from the main GUI command console, menu or module tree.
This partially fulfills the original request for interactivity. However,
there is no point in backporting this change as there is no standard
coordinates option in GRASS 6.4 and more importantly no mouse coordinates
picking from generated module forms/dialogs.
In trunk, G7:r.viewshed already has this standard coordinates option which
is supported by wxGUI. G7:r.los does not.
Neither of these three supports multiple coordinates input, although
G7:r.lake supports it using seed raster which makes more sense in this
case except for cases when you want to add just few points (e.g. 2). The
important thing is that supporting multiple coordinates goes far behind
supporting more inputs, probably algorithm itself needs to be improved to
fulfill the multiple point input required by the original request.
Separate tickets for each modules would be better in this case.
I'm not sure what is more advantageous, if `G_OPT_F_INPUT` or
`G_OPT_M_COORDS` with `multiple=yes` (I'm not sure how this is currently
supported by GUI). The later would create less fields in GUI and less
options. The former would partially replace `G_OPT_M_COORDS`, so there
would be no possibility to input coordinates interactively (I mean mouse
clicks on map, not writing the file content into dialog).
The solution would be to leave also the `G_OPT_M_COORDS` option (so in GUI
there would be 4 possible inputs for `r.lake`: 2 for file, 1 raster, 1
coordinates). The alternative to many input fields is to create a new
(GRASS) type `file with coordinates` which could recognized by GUI, so
that it would behave similarly to `G_OPT_M_COORDS`.
The vector point layer is also interesting but for `r.lake` it would
create 4th option how to input data (and vector could support also lines
and areas to make it even more complicated).
The GUI part of `G_OPT_M_COORDS` cannot be backported easily, so 6 and 7
would require different solutions to this problem, so I think that this
ticket cannot be solved for GRASS 6 but it would be nice to solve it for
trunk.
The only thing which might be possible to add to GRASS 6 wxGUI is the
right click on map which gives you possibility to copy coordinates pair.
Note that wxGUI does not care if the coordinates are inputted to module by
parameter or standard input, actually, standard input might be easier to
write. Note some modules in GRASS 7, mainly related to temporal framework,
which supports parameter and file to input multiple maps (for cases when
the number of maps is really large), for example see G7:r.colors.
''I know, this was long, sorry.''
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1635#comment:3>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list