Opened 10 years ago

Closed 6 years ago

#675 closed defect (fixed)

r.proj's "use different location" error while working in different dbases

Reported by: nikos Owned by: grass-dev@…
Priority: major Milestone: 6.4.4
Component: Raster Version: unspecified
Keywords: r.proj, dbase, location, indbase->answer, inlocation->answer Cc: nikos.alexandris@…
CPU: Unspecified Platform: Unspecified

Description

I have "wgs84" locations in different dbases, for example: "/grassdb/ellas/wgs84" and "/grassdb/global/wgs84".

I want to "r.proj" something from "ellas" to "global" dbase and I get the following error:

--- # working in "global" g.gisenv

GISDBASE=/geo/grassdb/global LOCATION_NAME=wgs84 MAPSET=PERMANENT

# trying to "pull" data r.proj aster_gdem out=aster_gdem_ellas location=wgs84 mapset=PERMANENT dbase=/geo/grassdb/ellas

ERROR: You have to use a different location for input than the current ---

Even though r.proj is meant to re-project data from one location to another (= usually different projection definitions) within a dbase, it could be used to "pull" data from a different grass-dbase as in my example-attempt above.

This is a bug, ins't it? I suppose the "dbase=" parameter is not checked at all in this case (?).

Alternative solution with respect to the specific example here: allow g.copy to copy data from another dbase/location to the current dbase in a location with identical name and projection definition of course (?).

Change History (5)

comment:1 Changed 10 years ago by hamish

Priority: blockermajor

the bug appears as follows. r.proj(.seg) has the following check:

if (strcmp(inlocation->answer, G_location()) == 0)

G_fatal_error(_("You have to use a different location for input than the current"));

which fails if the location name is the same in both gisdbases. does it work if you leave the location= option blank? (default for mapsets is to assume the same, maybe location name too)

as a solution maybe the code should assemble "%s/%s", indbase->answer, inlocation->answer and test that string against G_location_path(). ? would that lead to dirsep hell?

Hamish

ps- cc'ing yourself is generally not needed, as a bug submitter or commenter you should be emailed any change through your osgeo id. less spam that way.

comment:2 in reply to:  1 ; Changed 10 years ago by nikos

Replying to hamish:

(Off-Topic)

ps- cc'ing yourself is generally not needed, as a bug submitter or commenter you should be emailed any change through your osgeo id. less spam that way.

This is a "known" problem for me. I have never received a trac-notification from grass-trac. Frank Warmerdam and Howard Butler know about this. I don't know if Howard has resolved the problem. I do know that I receive e-mail from qgis-trac.

Nikos

comment:3 in reply to:  1 Changed 10 years ago by nikos

Replying to hamish:

the bug appears as follows. r.proj(.seg) has the following check:

if (strcmp(inlocation->answer, G_location()) == 0)

G_fatal_error(_("You have to use a different location for input than the current"));

which fails if the location name is the same in both gisdbases. does it work if you leave the location= option blank? (default for mapsets is to assume the same, maybe location name too)

No, it does not work and the error message (correctly I suppose) is: ERROR: G_getenv(): Variable LOCATION_NAME not set

Nikos

comment:4 in reply to:  2 Changed 9 years ago by nikos

Replying to nikos:

Replying to hamish:

(Off-Topic)

ps- cc'ing yourself is generally not needed, as a bug submitter or commenter you should be emailed any change through your osgeo id. less spam that way.

This is a "known" problem for me. I have never received a trac-notification from grass-trac. Frank Warmerdam and Howard Butler know about this. I don't know if Howard has resolved the problem. I do know that I receive e-mail from qgis-trac.

(Off-Topic continued (and fixed))

Some months ago already I started receiving trac messages ;-)

comment:5 Changed 6 years ago by nikos

Milestone: 6.4.06.4.4
Resolution: fixed
Status: newclosed

This seems to work in both grass 64 and 7. Marking as "fixed".

ps- I regained access to my old account "nikos". Will only act, with this username, upon past tickets created by this username! All present and future actions in trac with my "nikosa" account. Sorry for this.

Note: See TracTickets for help on using tickets.