[GRASS-dev] r.out.gdal rewritten
landa.martin at gmail.com
Thu Oct 26 03:01:27 EDT 2006
2006/10/25, Glynn Clements <glynn at gclements.plus.com>:
> Martin Landa wrote:
> > > it is bad to put any non parser code before G_parser():
> > >
> > > http://article.gmane.org/gmane.comp.gis.grass.devel/12473/
> > > http://article.gmane.org/gmane.comp.gis.grass.devel/5224
> > > http://article.gmane.org/gmane.comp.gis.grass.devel/12446/
> > > http://article.gmane.org/gmane.comp.gis.grass.devel/7169
> > > ...
> > OK, you are right, on the other hand I don't know how to set
> > format->options dynamically based on GDAL installation without coding
> > before G_parser () function.
> You can't.
> > So might I ask you how to solve this problem?
> In this case, you have to use GDAL to set up the option list before
> calling G_parser().
> It's more accurate to say that you shouldn't call other GRASS
> functions (except for G_gisinit(), G_define_*()) before calling
> G_parser(). It's safe to assume that functions from third-party
> libraries will never be affected by command-line options.
> Note that this still precludes dynamically generating option lists
> using GRASS functions. That's inevitable; if you try to use GRASS
> functions to generate option lists, the values which those functions
> return might be affected by command-line options, so you end up with a
> chicken-and-egg problem. This will become a major issue if we add
> built-in options to G_parser() which allow global settings (e.g.
> environment variables or $GISRC settings) to be overridden.
Glynn, thanks for explanation!
If there are no objections I will commit it to CVS (raster/r.out.gdal,
module name r.out.gdal2).
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *
More information about the grass-dev