Nikos Alexandris nik at nikosalexandris.net
Fri Nov 14 06:31:28 PST 2014

On 14.11.2014 16:22, Moritz Lennert wrote:
> On 14/11/14 14:58, Nikos Alexandris wrote:
>> Nikos Alexandris wrote:
>>>>>> What is the difference between G_OPT_R_MAP and G_OPT_R_INPUT?
>>>>>> Which and
>>>>>> why should I prefer for my script(s)?
>>>>>> Is there a step-by-step run-through of all options for composing
>>>>>> header
>>>>>> definitions?
>> Helmut Kudrnovsky wrote:
>>>>> see
>>>>> http://grass.osgeo.org/programming7/gis_8h.html#a5521b5269c52afe64e5051348b08fc69
>> Benjamin Ducke wrote:
>>>> But that table doesn't really answer the question,
>>>> does it? For both "G_OPT_R_INPUT" and "G_OPT_R_MAP"
>>>> it lists "old input raster map". AFAIU, "G_OPT_R_MAP"
>>>> is for modules that use only one input raster map.
>>>> In those cases, the corresponding input option should
>>>> be named "map=". "G_OPT_R_INPUT" would then be for
>>>> modules that have either several raster map inputs or
>>>> raster and vector maps as inputs. The corresponding
>>>> input options would then be called "raster=" and
>>>> "vector=" in case of exactly one raster and one vector
>>>> input map. Further special cases are covered by
>>>> "G_OPT_R_BASE", "G_OPT_R_ELEV", etc.: They all exist
>>>> for semantical purposes. All of them stand for raster
>>>> input maps.
>> Moritz Lennert wrote:
>>> I've always understood the difference between MAP and INPUT as
>>> - MAP: used for modules which treat a map, but do not have
>>> input+output logic (e.g. r.category, r.colors, etc)
>>> - INPUT: used for modules that have input + output logic (r.cost,
>>> r.mfilter, etc)
>>> The difference between one or multiple inputs is covered by
>> So, then we have:
>> G_OPT_R_INPUT -> single raster map for modules featuring output(s)
>> G_OPT_R_INPUTS -> multiple input raster maps for modules feat.
>> output(s)
>> G_OPT_R_MAP -> single raster map for modules operating on "this" map
>> G_OPT_R_MAPS -> multiple raster maps for modules operating on 
>> "these"
>> maps
>> Right?
> At least that is how I've always interpreted it. You'd have to check
> individual modules if this is actually how things have been 
> applied...

Already did. Some counts for the scripts inside 


More information about the grass-dev mailing list