[GRASS-dev] GRASS 7: renaming of some modules

GRASS GRASS developer
,
1

Hi,

I would like to rename a set of modules as outlined in
http://grass.osgeo.org/wiki/GRASS_7_ideas_collection#rename

Raster:
* rename r.in.gdal to r.import
* rename r.out.gdal to r.export

Vector:
* rename v.in.ogr to v.import
* rename v.out.ogr to v.export
* rename v.mkgrid to v.grid

Database:
* rename db.in.ogr to db.import

Any objections (the motivation is obvious)? I would also update
gui/wxpython/gui_modules/menudata.py

to reflect the change as well as the manual pages.

Markus

2

On Sat, 11 Oct 2008, Markus Neteler wrote:

Hi,

I would like to rename a set of modules as outlined in
http://grass.osgeo.org/wiki/GRASS_7_ideas_collection#rename

Raster:
* rename r.in.gdal to r.import
* rename r.out.gdal to r.export

Vector:
* rename v.in.ogr to v.import
* rename v.out.ogr to v.export
* rename v.mkgrid to v.grid

Database:
* rename db.in.ogr to db.import

Any objections (the motivation is obvious)? I would also update

Hi Markus,
Can you elaborate on the motivation? As it is I feel an obvious objection is that this implies there is no other way to import raster and vector data than through GDAL and OGR respectively - but I count 8 r.in.*, 14 r.out.*, 4 v.in.* and 6 v.out.* modules in 7.x. So IMHO it is confusing.

Also v.mkgrid is IMHO clearer than v.grid - in the latter it is not so obvious what the module does with the grid. I guess it is consistent with the names of other vector modules though. But changing a module's name is always confusing (choice of a good initial name for a new module is thus VERY important).

Paul

3

On Sun, Oct 12, 2008 at 5:43 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:

On Sat, 11 Oct 2008, Markus Neteler wrote:

Hi,

I would like to rename a set of modules as outlined in
http://grass.osgeo.org/wiki/GRASS_7_ideas_collection#rename

Raster:
* rename r.in.gdal to r.import
* rename r.out.gdal to r.export

Vector:
* rename v.in.ogr to v.import
* rename v.out.ogr to v.export
* rename v.mkgrid to v.grid

Database:
* rename db.in.ogr to db.import

Any objections (the motivation is obvious)? I would also update

Hi Markus,
Can you elaborate on the motivation? As it is I feel an obvious objection is
that this implies there is no other way to import raster and vector data
than through GDAL and OGR respectively - but I count 8 r.in.*, 14 r.out.*, 4
v.in.* and 6 v.out.* modules in 7.x. So IMHO it is confusing.

Well, teaching GRASS over the year almost always brought up the
newcomer question: "Where [censored] is the import module?".
r.in.gdal or v.in.ogr is *not* obvious at all.
Since GDAL support 50+ formats, it's a quite good approximation.
Additionally, not (yet)part of my request, a subset of the r|v.in.* might
be retired since r.in.gdal/v.in.ogr meanwhile do the job.

Also, if r.import/v.import fail, still r.in.*/v.in.* are there as
further possibility.

Also v.mkgrid is IMHO clearer than v.grid - in the latter it is not so
obvious what the module does with the grid. I guess it is consistent with
the names of other vector modules though.

Ok, for me that's not very important.

But changing a module's name is
always confusing (choice of a good initial name for a new module is thus
VERY important).

Yes. This was missed with r.in.gdal/v.in.ogr.

Markus

4

On Sun, 12 Oct 2008, Markus Neteler wrote:

Any objections (the motivation is obvious)? I would also update

Hi Markus,
Can you elaborate on the motivation? As it is I feel an obvious objection is
that this implies there is no other way to import raster and vector data
than through GDAL and OGR respectively - but I count 8 r.in.*, 14 r.out.*, 4
v.in.* and 6 v.out.* modules in 7.x. So IMHO it is confusing.

Well, teaching GRASS over the year almost always brought up the
newcomer question: "Where [censored] is the import module?".
r.in.gdal or v.in.ogr is *not* obvious at all.

Thanks - surprisingly it wasn't actually obvious to me that the motive was newbie confusion! And yes I agree, good point - I also vaguely remember when starting GRASS being confused as to when r.in.gdal might be useful. And taken alone, r.import and r.export are very good names, easy to remember and also quick to type. I guess it's just the inconsistency that will then exist with r.in.* and r.out.* that I'm concerned about.

If r.in.gdal was renamed to something like r.in.multi or r.in.various that would be one way of preserving the consistency. Renaming r.in.* to r.import.* and r.out.* to r.export.* at the same time as renaming r.in.gdal to r.import would be another possiblity for preserving consistency. Neither of those are ideal; I'm not seriously suggesting either of them.

Is the idea of the proposal then to make new users see r.import as the standard import tool they should try first, and that r.in.* are legacy modules to look at if they have difficulty or special requirements? If so, I guess I'm generally in favour of it after all.

Paul

5

Hello Paul and Markus,

at some point would it be useful to get an Import Wizard up and running?
It would call the necessary r.in* or v.in* according to needed formats…

Michael and I worked on a wxWizard at some point,
maybe it could be a good time to resurrect that work?

Yann

2008/10/13 Paul Kelly <paul-grass@stjohnspoint.co.uk>

On Sun, 12 Oct 2008, Markus Neteler wrote:

Any objections (the motivation is obvious)? I would also update

Hi Markus,
Can you elaborate on the motivation? As it is I feel an obvious objection is
that this implies there is no other way to import raster and vector data
than through GDAL and OGR respectively - but I count 8 r.in., 14 r.out., 4
v.in.* and 6 v.out.* modules in 7.x. So IMHO it is confusing.

Well, teaching GRASS over the year almost always brought up the
newcomer question: “Where [censored] is the import module?”.
r.in.gdal or v.in.ogr is not obvious at all.

Thanks - surprisingly it wasn’t actually obvious to me that the motive was newbie confusion! And yes I agree, good point - I also vaguely remember when starting GRASS being confused as to when r.in.gdal might be useful. And taken alone, r.import and r.export are very good names, easy to remember and also quick to type. I guess it’s just the inconsistency that will then exist with r.in.* and r.out.* that I’m concerned about.

If r.in.gdal was renamed to something like r.in.multi or r.in.various that would be one way of preserving the consistency. Renaming r.in.* to r.import.* and r.out.* to r.export.* at the same time as renaming r.in.gdal to r.import would be another possiblity for preserving consistency. Neither of those are ideal; I’m not seriously suggesting either of them.

Is the idea of the proposal then to make new users see r.import as the standard import tool they should try first, and that r.in.* are legacy modules to look at if they have difficulty or special requirements? If so, I guess I’m generally in favour of it after all.

Paul

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
YiKingDo: http://yikingdo.unblog.fr/