[GRASS-dev] G_OPT_R_MAP vs G_OPT_R_INPUT
Moritz Lennert
mlennert at club.worldonline.be
Fri Nov 14 06:22:32 PST 2014
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
>> G_OPT_R_INPUT vs G_OPT_R_INPUTS.
>
> 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...
Moritz
More information about the grass-dev
mailing list