[GRASS-dev] r.out.gdal rewritten

[Martin Landa]

Hi,

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).

Best, Martin


-- 
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *