[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