[GRASS-dev] r.out.gdal rewritten

Vytautas · October 24, 2006, 3:40am

Hello, everybody

I have just rewritten r.out.gdal in C language, made it based on GDAL
library. I think it should replace current r.out.gdal script based on
gdal_translate executable.

It should help to avoid cyclic GRASS and GDAL dependence.

Not fully implemented, but it works. Please test it and/or add
aditional features.

Regards,
Vytautas

(attachments)

r.out.gdal.tar.gz (3.56 KB)

martinl · October 24, 2006, 7:39am

Hi Vytautas,

it is great, thanks a lot for this!! There is small patch (not
important changes). I think it should be added to CVS as r.out.gdal2
(e.g.) for faster improvements (and testing).

Best regards, Martin

2006/10/24, Vytautas <olivership@gmail.com>:

Hello, everybody

I have just rewritten r.out.gdal in C language, made it based on GDAL
library. I think it should replace current r.out.gdal script based on
gdal_translate executable.

It should help to avoid cyclic GRASS and GDAL dependence.

Not fully implemented, but it works. Please test it and/or add
aditional features.

Regards,
Vytautas

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

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

(attachments)

main.c.diff.gz (1.25 KB)

mlennert · October 24, 2006, 9:29am

On Tue, October 24, 2006 09:39, Martin Landa wrote:

Hi Vytautas,

it is great, thanks a lot for this!! There is small patch (not
important changes).

This patch introduces a small error:

@@ -138,12 +146,8 @@
flag_l->key = 'l';
flag_l->description = _("list supported output formats");

- input = G_define_option();
- input->key = "input";
- input->type = TYPE_STRING;
- input->gisprompt = "old,cell,raster";
- input->description = _("Name of input raster map");
- input->required = NO;
+ input = G_define_standard_option(G_OPT_R_INPUT);
+ format->required = NO;

The last line should obviously be

input->required = NO;

Moritz

mlennert · October 24, 2006, 9:34am

Another question:

Any reason that the available formats are limited to

format->options = "AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF2,NITF,PAux,PNG,PNM,VRT,XPM";

When the '-l' flag prints these formats as available:

   GRASS (ro): GRASS Database Rasters (5.7+)
   VRT (rw+): Virtual Raster
   GTiff (rw+): GeoTIFF
   NITF (rw+): National Imagery Transmission Format
   HFA (rw+): Erdas Imagine Images (.img)
   SAR_CEOS (ro): CEOS SAR Image
   CEOS (ro): CEOS Image
   ELAS (rw+): ELAS
   AIG (ro): Arc/Info Binary Grid
   AAIGrid (rw): Arc/Info ASCII Grid
   SDTS (ro): SDTS Raster
   DTED (rw): DTED Elevation Raster
   PNG (rw): Portable Network Graphics
   JPEG (rw): JPEG JFIF
   MEM (rw+): In Memory Raster
   JDEM (ro): Japanese DEM (.mem)
   GIF (rw): Graphics Interchange Format (.gif)
   ESAT (ro): Envisat Image Format
   FITS (rw+): Flexible Image Transport System
   BSB (ro): Maptech BSB Nautical Charts
   XPM (rw): X11 PixMap Format
   BMP (rw+): MS Windows Device Independent Bitmap
   AirSAR (ro): AirSAR Polarimetric Image
   RS2 (ro): RadarSat 2 XML Product
   PCIDSK (rw+): PCIDSK Database File
   PCRaster (rw): PCRaster Raster File
   ILWIS (rw+): ILWIS Raster Map
   RIK (ro): Swedish Grid RIK (.rik)
   SGI (ro): SGI Image File Format 1.0
   Leveller (ro): Leveller heightfield
   GMT (rw): GMT NetCDF Grid Format
   netCDF (rw): Network Common Data Format
   HDF4 (ro): Hierarchical Data Format Release 4
   HDF4Image (rw+): HDF4 Dataset
   PNM (rw+): Portable Pixmap Format (netpbm)
   DOQ1 (ro): USGS DOQ (Old Style)
   DOQ2 (ro): USGS DOQ (New Style)
   ENVI (rw+): ENVI .hdr Labelled
   EHdr (rw+): ESRI .hdr Labelled
   PAux (rw+): PCI .aux Labelled
   MFF (rw+): Vexcel MFF Raster
   MFF2 (rw+): Vexcel MFF2 (HKV) Raster
   FujiBAS (ro): Fuji BAS Scanner Image
   GSC (ro): GSC Geogrid
   FAST (ro): EOSAT FAST Format
   BT (rw+): VTP .bt (Binary Terrain) 1.3 Format
   LAN (ro): Erdas .LAN/.GIS
   CPG (ro): Convair PolGASP
   IDA (rw+): Image Data and Analysis
   NDF (ro): NLAPS Data Format
   DIPEx (ro): DIPEx
   ISIS2 (ro): USGS Astrogeology ISIS cube (Version 2)
   JPEG2000 (rw): JPEG-2000 part 1 (ISO/IEC 15444-1)
   L1B (ro): NOAA Polar Orbiter Level 1b Data Set
   FIT (rw): FIT Image
   RMF (rw+): Raster Matrix Format
   RST (rw+): Idrisi Raster A.1
   USGSDEM (rw): USGS Optional ASCII DEM (and CDED)
   GXF (ro): GeoSoft Grid Exchange Format

?

Moritz

Roger_Bivand · October 24, 2006, 9:52am

On Tue, 24 Oct 2006, Moritz Lennert wrote:

Another question:

Any reason that the available formats are limited to

format->options =
"AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF2,NITF,PAux,PNG,PNM,VRT,XPM";

Aren't they the formats with either (rw) or (rw+), no (ro)?

Roger

When the '-l' flag prints these formats as available:

   GRASS (ro): GRASS Database Rasters (5.7+)
   VRT (rw+): Virtual Raster
   GTiff (rw+): GeoTIFF
   NITF (rw+): National Imagery Transmission Format
   HFA (rw+): Erdas Imagine Images (.img)
   SAR_CEOS (ro): CEOS SAR Image
   CEOS (ro): CEOS Image
   ELAS (rw+): ELAS
   AIG (ro): Arc/Info Binary Grid
   AAIGrid (rw): Arc/Info ASCII Grid
   SDTS (ro): SDTS Raster
   DTED (rw): DTED Elevation Raster
   PNG (rw): Portable Network Graphics
   JPEG (rw): JPEG JFIF
   MEM (rw+): In Memory Raster
   JDEM (ro): Japanese DEM (.mem)
   GIF (rw): Graphics Interchange Format (.gif)
   ESAT (ro): Envisat Image Format
   FITS (rw+): Flexible Image Transport System
   BSB (ro): Maptech BSB Nautical Charts
   XPM (rw): X11 PixMap Format
   BMP (rw+): MS Windows Device Independent Bitmap
   AirSAR (ro): AirSAR Polarimetric Image
   RS2 (ro): RadarSat 2 XML Product
   PCIDSK (rw+): PCIDSK Database File
   PCRaster (rw): PCRaster Raster File
   ILWIS (rw+): ILWIS Raster Map
   RIK (ro): Swedish Grid RIK (.rik)
   SGI (ro): SGI Image File Format 1.0
   Leveller (ro): Leveller heightfield
   GMT (rw): GMT NetCDF Grid Format
   netCDF (rw): Network Common Data Format
   HDF4 (ro): Hierarchical Data Format Release 4
   HDF4Image (rw+): HDF4 Dataset
   PNM (rw+): Portable Pixmap Format (netpbm)
   DOQ1 (ro): USGS DOQ (Old Style)
   DOQ2 (ro): USGS DOQ (New Style)
   ENVI (rw+): ENVI .hdr Labelled
   EHdr (rw+): ESRI .hdr Labelled
   PAux (rw+): PCI .aux Labelled
   MFF (rw+): Vexcel MFF Raster
   MFF2 (rw+): Vexcel MFF2 (HKV) Raster
   FujiBAS (ro): Fuji BAS Scanner Image
   GSC (ro): GSC Geogrid
   FAST (ro): EOSAT FAST Format
   BT (rw+): VTP .bt (Binary Terrain) 1.3 Format
   LAN (ro): Erdas .LAN/.GIS
   CPG (ro): Convair PolGASP
   IDA (rw+): Image Data and Analysis
   NDF (ro): NLAPS Data Format
   DIPEx (ro): DIPEx
   ISIS2 (ro): USGS Astrogeology ISIS cube (Version 2)
   JPEG2000 (rw): JPEG-2000 part 1 (ISO/IEC 15444-1)
   L1B (ro): NOAA Polar Orbiter Level 1b Data Set
   FIT (rw): FIT Image
   RMF (rw+): Raster Matrix Format
   RST (rw+): Idrisi Raster A.1
   USGSDEM (rw): USGS Optional ASCII DEM (and CDED)
   GXF (ro): GeoSoft Grid Exchange Format

?

Moritz

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand@nhh.no

mlennert · October 24, 2006, 11:15am

Roger Bivand wrote:

On Tue, 24 Oct 2006, Moritz Lennert wrote:

Another question:

Any reason that the available formats are limited to

format->options = "AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF2,NITF,PAux,PNG,PNM,VRT,XPM";

Aren't they the formats with either (rw) or (rw+), no (ro)?

The following are rw(+) and are not in the list:

   FITS (rw+): Flexible Image Transport System
   PCIDSK (rw+): PCIDSK Database File
   PCRaster (rw): PCRaster Raster File
   ILWIS (rw+): ILWIS Raster Map
   GMT (rw): GMT NetCDF Grid Format
   netCDF (rw): Network Common Data Format
   HDF4Image (rw+): HDF4 Dataset
   EHdr (rw+): ESRI .hdr Labelled
   BT (rw+): VTP .bt (Binary Terrain) 1.3 Format
   IDA (rw+): Image Data and Analysis
   JPEG2000 (rw): JPEG-2000 part 1 (ISO/IEC 15444-1)
   RMF (rw+): Raster Matrix Format
   RST (rw+): Idrisi Raster A.1
   USGSDEM (rw): USGS Optional ASCII DEM (and CDED)

Moritz

martinl · October 24, 2006, 12:38pm

Hi,

I have tried to improve C version r.out.gdal, see the attached patch.

Best regards, Martin

2006/10/24, Moritz Lennert <mlennert@club.worldonline.be>:

Roger Bivand wrote:
> On Tue, 24 Oct 2006, Moritz Lennert wrote:
>
>> Another question:
>>
>> Any reason that the available formats are limited to
>>
>> format->options =
>> "AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF2,NITF,PAux,PNG,PNM,VRT,XPM";
>
> Aren't they the formats with either (rw) or (rw+), no (ro)?
>

The following are rw(+) and are not in the list:

>> FITS (rw+): Flexible Image Transport System
>> PCIDSK (rw+): PCIDSK Database File
>> PCRaster (rw): PCRaster Raster File
>> ILWIS (rw+): ILWIS Raster Map
>> GMT (rw): GMT NetCDF Grid Format
>> netCDF (rw): Network Common Data Format
>> HDF4Image (rw+): HDF4 Dataset
>> EHdr (rw+): ESRI .hdr Labelled
>> BT (rw+): VTP .bt (Binary Terrain) 1.3 Format
>> IDA (rw+): Image Data and Analysis
>> JPEG2000 (rw): JPEG-2000 part 1 (ISO/IEC 15444-1)
>> RMF (rw+): Raster Matrix Format
>> RST (rw+): Idrisi Raster A.1
>> USGSDEM (rw): USGS Optional ASCII DEM (and CDED)

Moritz

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

(attachments)

main.c-2.diff.gz (2.02 KB)

mlennert · October 24, 2006, 1:11pm

Martin Landa wrote:

Hi,

I have tried to improve C version r.out.gdal, see the attached patch.

I had to add $(DBMILIB) to the LIBES line of the Makfile, but then it runs great, including the check for available formats. I got some error messages with JPEG2000 and USGSDEM, but these seemed to be format specific and not a problem in r.out.gdal.

Moritz

Best regards, Martin

2006/10/24, Moritz Lennert <mlennert@club.worldonline.be>:

Roger Bivand wrote:
> On Tue, 24 Oct 2006, Moritz Lennert wrote:
>
>> Another question:
>>
>> Any reason that the available formats are limited to
>>
>> format->options =
>> "AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF2,NITF,PAux,PNG,PNM,VRT,XPM";

>
> Aren't they the formats with either (rw) or (rw+), no (ro)?
>

The following are rw(+) and are not in the list:

>> FITS (rw+): Flexible Image Transport System
>> PCIDSK (rw+): PCIDSK Database File
>> PCRaster (rw): PCRaster Raster File
>> ILWIS (rw+): ILWIS Raster Map
>> GMT (rw): GMT NetCDF Grid Format
>> netCDF (rw): Network Common Data Format
>> HDF4Image (rw+): HDF4 Dataset
>> EHdr (rw+): ESRI .hdr Labelled
>> BT (rw+): VTP .bt (Binary Terrain) 1.3 Format
>> IDA (rw+): Image Data and Analysis
>> JPEG2000 (rw): JPEG-2000 part 1 (ISO/IEC 15444-1)
>> RMF (rw+): Raster Matrix Format
>> RST (rw+): Idrisi Raster A.1
>> USGSDEM (rw): USGS Optional ASCII DEM (and CDED)

Moritz

cmbarton · October 24, 2006, 3:12pm

This will be a BIG help for many.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Martin Landa <landa.martin@gmail.com>
Date: Tue, 24 Oct 2006 09:39:44 +0200
To: Vytautas <olivership@gmail.com>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] r.out.gdal rewritten

Hi Vytautas,

it is great, thanks a lot for this!! There is small patch (not
important changes). I think it should be added to CVS as r.out.gdal2
(e.g.) for faster improvements (and testing).

Best regards, Martin

2006/10/24, Vytautas <olivership@gmail.com>:

Hello, everybody

I have just rewritten r.out.gdal in C language, made it based on GDAL
library. I think it should replace current r.out.gdal script based on
gdal_translate executable.

It should help to avoid cyclic GRASS and GDAL dependence.

Not fully implemented, but it works. Please test it and/or add
aditional features.

Regards,
Vytautas

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

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

Andrew_Danner1 · October 24, 2006, 3:17pm

I'm all for replacing the r.out.gdal script, but one problem I have with
the new C version of r.out.gdal is that it creates a temporary raster
entirely in memory and won't work with rasters larger than 2GB, of which
I have many. It would be nice if the temp raster format that is
currently the "MEM" supported the following

1) GDALCreate
2a) GDALSetRasterNoDataValue,
2b) remapping of NULL values,
3) Grass datatypes Float32, Float64, and Int32
4) Multiple Bands
5) GDALSetGeoTransform, GDALSetProjection
6) GDALSetRasterColorInterpretation ??
(used in new r.out.gdal, but required?)
7) Files larger than 2GB

The final output format created using GDALCreateCopy may not support all
of these features depending on the target format, but we shouldn't lose
anything that is supported in GRASS when creating the temp copy,
including large files.

In the past, I have used the "EHdr" driver to support 1,2b,3, and 7.
Then I could save the Transform and Projection information elsewhere. I
seem to recall GDAL didn't fully support 5 for "EHdr" in the sense that
it wouldn't write a .prj or .wld file for newly created "EHdr" files.

The "MEM" file format has all of the requirements except #7, but it
isn't just a matter of fixing the "MEM" driver. Is there a file format
that is basically a file dump of "MEM"?

-Andy

On Tue, 2006-10-24 at 09:39 +0200, Martin Landa wrote:

Hi Vytautas,

it is great, thanks a lot for this!! There is small patch (not
important changes). I think it should be added to CVS as r.out.gdal2
(e.g.) for faster improvements (and testing).

Best regards, Martin

2006/10/24, Vytautas <olivership@gmail.com>:
> Hello, everybody
>
> I have just rewritten r.out.gdal in C language, made it based on GDAL
> library. I think it should replace current r.out.gdal script based on
> gdal_translate executable.
>
> It should help to avoid cyclic GRASS and GDAL dependence.
>
> Not fully implemented, but it works. Please test it and/or add
> aditional features.
>
> Regards,
> Vytautas
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>
>
>

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Glynn_Clements1 · October 24, 2006, 9:34pm

Martin Landa wrote:

it is great, thanks a lot for this!! There is small patch (not
important changes). I think it should be added to CVS as r.out.gdal2
(e.g.)

Add it as raster/r.out.gdal (the existing script is in the scripts
directory). You can name the executable r.out.gdal2 while it's being
tested then change it to r.out.gdal when it's stable, but we don't
want to have to rename the directory later.

--
Glynn Clements <glynn@gclements.plus.com>

H_B · October 25, 2006, 3:19am

Any reason that the available formats are limited to

format->options =
"AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF2,
NITF,PAux,PNG,PNM,VRT,XPM";

don't hardcode the available formats. They will depend on the local
installation of GDAL, and what configure flags it was built with, and as
such options will vary widely. If you hard code it you impose an
artificial barrier to optional and future raster formats.

depend on "r.out.gdal -l" and examples (GTiff) instead.

Hamish

martinl · October 25, 2006, 4:56am

Hi all,

2006/10/24, Glynn Clements <glynn@gclements.plus.com>:

Martin Landa wrote:

[ship]

Add it as raster/r.out.gdal (the existing script is in the scripts
directory). You can name the executable r.out.gdal2 while it's being
tested then change it to r.out.gdal when it's stable, but we don't
want to have to rename the directory later.

understand, I can do it today, if desired.

Best regards, Martin

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

H_B · October 25, 2006, 5:21am

Hamish wrote:
> > format->options =
> > "AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MF
> > F2, NITF,PAux,PNG,PNM,VRT,XPM";
>
> don't hardcode the available formats. They will depend on the local
> installation of GDAL, and what configure flags it was built with,
> and as such options will vary widely. If you hard code it you impose
> an artificial barrier to optional and future raster formats.
>
> depend on "r.out.gdal -l" and examples (GTiff) instead.

Vytautas wrote:

List of avaible formats in format options is now generated dynamicly.

G_gisinit (argv[0]);

+ /* Init GDAL */
+ GDALAllRegister();
+
        module = G_define_module();
[..]
+
+ supported_formats(&gdal_formats);
+
        format = G_define_option();
        format->key = "format";
        format->type = TYPE_STRING;
        format->description = _("GIS format to write (case sensitive, see also -l flag)");
- format->options = "AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF2,N
ITF,PAux,PNG,PNM,VRT,XPM";
+ /* format->options = "AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF
2,NITF,PAux,PNG,PNM,VRT,XPM"; */
+ if (gdal_formats)
+ format->options = G_store (gdal_formats);
+ else
+ G_fatal_error (_("Unknown GIS formats"));
+
        format->answer = "GTiff";
        format->required = NO;

[..]

if (G_parser(argc,argv)) exit(EXIT_FAILURE);

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

Hamish

martinl · October 25, 2006, 4:42pm

Hi,

2006/10/25, Hamish <hamish_nospam@yahoo.com>:

> Hamish wrote:
> > > format->options =
> > > "AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MF
> > > F2, NITF,PAux,PNG,PNM,VRT,XPM";
> >
> > don't hardcode the available formats. They will depend on the local
> > installation of GDAL, and what configure flags it was built with,
> > and as such options will vary widely. If you hard code it you impose
> > an artificial barrier to optional and future raster formats.
> >
> > depend on "r.out.gdal -l" and examples (GTiff) instead.

Vytautas wrote:
> List of avaible formats in format options is now generated dynamicly.

        G_gisinit (argv[0]);

+ /* Init GDAL */
+ GDALAllRegister();
+
        module = G_define_module();
[..]
+
+ supported_formats(&gdal_formats);
+
        format = G_define_option();
        format->key = "format";
        format->type = TYPE_STRING;
        format->description = _("GIS format to write (case sensitive, see also -l flag)");
- format->options = "AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF2,N
ITF,PAux,PNG,PNM,VRT,XPM";
+ /* format->options = "AAIGrid,BMP,BSB,DTED,ELAS,ENVI,FIT,GIF,GTiff,HFA,JPEG,MEM,MFF,MFF
2,NITF,PAux,PNG,PNM,VRT,XPM"; */
+ if (gdal_formats)
+ format->options = G_store (gdal_formats);
+ else
+ G_fatal_error (_("Unknown GIS formats"));
+
        format->answer = "GTiff";
        format->required = NO;

[..]

        if (G_parser(argc,argv)) exit(EXIT_FAILURE);

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. So might I ask you how to solve this
problem?

Thanks!, best regards Martin

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

Glynn_Clements1 · October 25, 2006, 6:18pm

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 Clements <glynn@gclements.plus.com>

Glynn_Clements1 · October 25, 2006, 11:57pm

Andrew Danner wrote:

I'm all for replacing the r.out.gdal script, but one problem I have with
the new C version of r.out.gdal is that it creates a temporary raster
entirely in memory

That's unacceptable.

If I had realised that, I wouldn't have suggested committing it to
CVS. Unfortunately, I don't know enough about GDAL to fix it myself.

To anyone else working on the new r.out.gdal: don't waste too much
time working on it until someone figures out how to fix this issue. If
it can't be done, then the module will be removed.

--
Glynn Clements <glynn@gclements.plus.com>

martinl · October 26, 2006, 7:01am

Hi,

2006/10/25, Glynn Clements <glynn@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@gmail.com> * http://gama.fsv.cvut.cz/~landa *

marisn · October 26, 2006, 9:00am

Hi,

Sorry, I'm not reading related code, but does not many current GRASS modules
relay on loading whole raster map into ram? Not all GRASS modules scale
well

IMLO better working version today than excellent version tomorrow. Talks about
replacing r.out.gdal script w C module I hear for long time, but no one does.
Now we have an option, why not use it?

My 0.02,
Maris.

On Thursday 26 October 2006 02:57, Glynn Clements wrote:

Andrew Danner wrote:
> I'm all for replacing the r.out.gdal script, but one problem I have with
> the new C version of r.out.gdal is that it creates a temporary raster
> entirely in memory

That's unacceptable.

If I had realised that, I wouldn't have suggested committing it to
CVS. Unfortunately, I don't know enough about GDAL to fix it myself.

To anyone else working on the new r.out.gdal: don't waste too much
time working on it until someone figures out how to fix this issue. If
it can't be done, then the module will be removed.

Vytautas_V · October 26, 2006, 1:41pm

Hi everyone,

Solusion!

I updated r.out.gdal code - now it does not has 2GB limit, unless target driver has or target driver does not support direct writing.

If target driver supports GDALCreate (it means direct writing) - this driver is used to output GRASS raster (no more limits).
If target driver does not supports GDALCreate - MEM driver is used to create dataset (in memory) and than destination raster is created with GDALCreateCopy.

As I mentioned, new r.out.gdal code was created with idea that GDAL should not depend on GRASS while GRASS depend on GDAL (cyclic dependency looks abnormaly).

Regards,

Vytautas

On 10/26/06, Glynn Clements <glynn@gclements.plus.com> wrote:

Andrew Danner wrote:

I’m all for replacing the r.out.gdal script, but one problem I have with
the new C version of r.out.gdal is that it creates a temporary raster
entirely in memory

That’s unacceptable.

If I had realised that, I wouldn’t have suggested committing it to
CVS. Unfortunately, I don’t know enough about GDAL to fix it myself.

To anyone else working on the new r.out.gdal: don’t waste too much
time working on it until someone figures out how to fix this issue. If
it can’t be done, then the module will be removed.

–
Glynn Clements < glynn@gclements.plus.com>

grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

(attachments)

r.out.gdal.tar.gz (3.89 KB)