#675: r.proj's "use different location" error while working in different dbases
--------------------------------------------------------------------------+-
Reporter: nikos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: blocker | Milestone: 6.4.0
Component: Raster | Version: unspecified
Keywords: r.proj, dbase, location, indbase->answer, inlocation->answer | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------------------------------------------+-
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:
# 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 (?).
#675: r.proj's "use different location" error while working in different dbases
--------------------------+-------------------------------------------------
Reporter: nikos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: unspecified
Resolution: | Keywords: r.proj, dbase, location, indbase->answer, inlocation->answer
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Changes (by hamish):
* priority: blocker => major
Comment:
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.
#675: r.proj's "use different location" error while working in different dbases
--------------------------+-------------------------------------------------
Reporter: nikos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: unspecified
Resolution: | Keywords: r.proj, dbase, location, indbase->answer, inlocation->answer
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by nikos):
Replying to [comment:1 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.
#675: r.proj's "use different location" error while working in different dbases
--------------------------+-------------------------------------------------
Reporter: nikos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: unspecified
Resolution: | Keywords: r.proj, dbase, location, indbase->answer, inlocation->answer
Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Comment (by nikos):
Replying to [comment:1 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
#675: r.proj's "use different location" error while working in different dbases
--------------------------------------------------------------------------+-
Reporter: nikos | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: unspecified
Keywords: r.proj, dbase, location, indbase->answer, inlocation->answer | Platform: Unspecified
Cpu: Unspecified |
--------------------------------------------------------------------------+-
Comment(by nikos):
Replying to [comment:2 nikos]:
>
> Replying to [comment:1 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
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.
