[GRASS-dev] r.out.gdal2 -> r.out.gdal?

GRASS GIS GRASS GIS developer
,
1

hi,

are there objections to rename r.out.gdal2 to
r.out.gdal and remove the now obsolete
scripts/r.out.gdal/
?

I have used the C version quite a bit successfully.

Markus

2

Hi,

+1 for r.out.gdal2 -> r.out.gdal(C)

maybe it could be safer to rename the r.out.gdal(script) to
r.out.gdal2 or r.out.gdal.sh and to add an appropriate warning, e.g.

WARNING: This module is superseded and will be removed in future
versions of GRASS. Use r.out.gdal instead.

Martin

2006/12/1, Markus Neteler <neteler@itc.it>:

hi,

are there objections to rename r.out.gdal2 to
r.out.gdal and remove the now obsolete
scripts/r.out.gdal/
?

I have used the C version quite a bit successfully.

Markus

_______________________________________________
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 *

3

On 12/1/06 8:39 AM, "Markus Neteler" <neteler@itc.it> wrote:

hi,

are there objections to rename r.out.gdal2 to
r.out.gdal and remove the now obsolete
scripts/r.out.gdal/
?

I have used the C version quite a bit successfully.

Markus

PLEASE DO!

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

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

4

On 12/1/06 10:30 AM, "Martin Landa" <landa.martin@gmail.com> wrote:

+1 for r.out.gdal2 -> r.out.gdal(C)

I have a question. Will GRASS still need a full install of GDAL for
exporting via C-based r.out.gdal? Or can we drop this as a dependency?

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

5

Michael Barton wrote:

> +1 for r.out.gdal2 -> r.out.gdal(C)

I have a question. Will GRASS still need a full install of GDAL for
exporting via C-based r.out.gdal? Or can we drop this as a dependency?

What do you mean by a "full" install? GRASS needs GDAL regardless of
r.{in,out}.gdal.

You will need GDAL headers and library to build r.out.gdal, and the
library to run it.

OTOH, GDAL won't need to be built with GRASS support, so you don't
need to build GDAL without GRASS, build GDAL, then build it again with
GRASS (unless you need GDAL to have GRASS support for some other
reason).

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

6

On 12/2/06 3:58 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

What do you mean by a "full" install? GRASS needs GDAL regardless of
r.{in,out}.gdal.

You will need GDAL headers and library to build r.out.gdal, and the
library to run it.

OTOH, GDAL won't need to be built with GRASS support, so you don't
need to build GDAL without GRASS, build GDAL, then build it again with
GRASS (unless you need GDAL to have GRASS support for some other
reason).

Actually, it appears that I really had two questions. One you've answered.
The other is will GDAL need to be installed for GRASS binaries to work after
it has been built?

Thanks
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

7

Michael Barton wrote:

> What do you mean by a "full" install? GRASS needs GDAL regardless of
> r.{in,out}.gdal.
>
> You will need GDAL headers and library to build r.out.gdal, and the
> library to run it.
>
> OTOH, GDAL won't need to be built with GRASS support, so you don't
> need to build GDAL without GRASS, build GDAL, then build it again with
> GRASS (unless you need GDAL to have GRASS support for some other

Actually, it appears that I really had two questions. One you've answered.
The other is will GDAL need to be installed for GRASS binaries to work after
it has been built?

If you build GRASS against shared GDAL libraries, you will need those
libraries to run GRASS. If you use static GDAL libraries, you don't
need those to run GRASS, although you will still need any of GDAL's
dependencies which are themselves shared libraries.

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

8

Hi,

I have now:
- renamed the script 'r.out.gdal' to 'r.out.gdal.sh'
- added the 'superseded' therein
- activated the C version of r.out.gdal in the Makefile

This will also solve the problem that the latest QGIS Windows
test built fails on the r.out.gdal[.sh] script as it is
lacking gdal_translate in the install package.

Many thanks to Vytautas V. for writing the C implementation
which is region sensitive and FAST!

For the common r.out.gdal basically nothing changes except
for the region thing and speed.

Markus

On Fri, Dec 01, 2006 at 06:30:30PM +0100, Martin Landa wrote:

Hi,

+1 for r.out.gdal2 -> r.out.gdal(C)

maybe it could be safer to rename the r.out.gdal(script) to
r.out.gdal2 or r.out.gdal.sh and to add an appropriate warning, e.g.

WARNING: This module is superseded and will be removed in future
versions of GRASS. Use r.out.gdal instead.

Martin

2006/12/1, Markus Neteler <neteler@itc.it>:
>hi,
>
>are there objections to rename r.out.gdal2 to
>r.out.gdal and remove the now obsolete
>scripts/r.out.gdal/
>?
>
>I have used the C version quite a bit successfully.
>
>Markus
>
>_______________________________________________
>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 *

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

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

9

Hi,

glad to hear about new r.out.gdal being normally named and included in
the Makefile.

I also wanted to inform that new r.out.gdal also supports multiband
rasters! It is able to export group to multiband raster, if you enter
group's name as input (this can be useful when you need to export
image from GRASS).
But users are not informed about this capability nor GUI informs it.
I'm also thinking about adding flag -g to force group, if there is
individual raster and group with the same name (r.out.gdal first
searches individual raster, if not found - group with a given input
name).

Vytautas

10

Vytautas V wrote:

I'm also thinking about adding flag -g to force group, if there is
individual raster and group with the same name

that is a good idea.

(r.out.gdal first searches individual raster, if not found - group
with a given input name).

I'm not sure, maybe input= should be for raster maps only? (pulldown menus, etc)

group != raster map (the way a reclass raster map ~= raster map)

Hamish

11

On Mon, 11 Dec 2006, Hamish wrote:

Vytautas V wrote:

I'm also thinking about adding flag -g to force group, if there is
individual raster and group with the same name

that is a good idea.

(r.out.gdal first searches individual raster, if not found - group
with a given input name).

I'm not sure, maybe input= should be for raster maps only? (pulldown menus, etc)

group != raster map (the way a reclass raster map ~= raster map)

Yes, while in a way kind of neat the way it currently is, I think the most elegant way to handle this would be to have two separate input parameters: "input" for a raster map and "group" for an imagery group. And some sanity checks could be included in the module to exit with an error if both were specified by accident.

Paul

12

what about creating seperate module i.out.gdal for exporting groups?
It can be created from a copy of current r.out.gdal.

Vytautas

13

Vytautas V wrote on 12/13/2006 02:40 AM:

what about creating seperate module i.out.gdal for exporting groups?
It can be created from a copy of current r.out.gdal.

Vytautas,

copying code (cloning) is usually a bad thing since you have
to maintain identical code several times.
Personally I like the idea of having
raster=
group=
for r.out.gdal.

Markus