Nikos Alexandris wrote:
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
---
This is a bug, ins't it? I suppose the "dbase=" parameter
is not checked at all in this case (?).
yes, it appears so.
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"));
maybe it should assemble indbase->answer/inlocation->answer
and test that against G_location_path(). ? then dirsep hell?
please file a bug
Hamish
Nikos:
> 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:
> ERROR: You have to use a different location for input than
> the current
> This is a bug, ins't it? I suppose the "dbase=" parameter
> is not checked at all in this case (?).
Hamish:
yes, it appears so.
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"));
maybe it should assemble indbase->answer/inlocation->answer
and test that against G_location_path(). ? then dirsep hell?
please file a bug
Done: http://trac.osgeo.org/grass/ticket/675
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 (?).
Nikos
Nikos Alexandris wrote:
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 (?).
We don't currently have any way to check whether two projections are
identical, and this isn't a trivial question. E.g.:
1. Some of the parameters are floating-point values, so we would need
to choose some kind of tolerance.
2. Are WGS84 and NAD83 the same? In the absence of grid shift files,
the only difference is that the eccentricity of the WGS84 and GRS80
ellipsoids differ by 1.5e-6.
3. If the projections use grid shift files, do we just check that they
use the same file, or do we compare their contents?
--
Glynn Clements <glynn@gclements.plus.com>
Nikos Alexandris wrote:
> 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 (?).
Glynn Clements:
We don't currently have any way to check whether two projections are
identical, and this isn't a trivial question. E.g.:
1. Some of the parameters are floating-point values, so we would need
to choose some kind of tolerance.
2. Are WGS84 and NAD83 the same? In the absence of grid shift files,
the only difference is that the eccentricity of the WGS84 and GRS80
ellipsoids differ by 1.5e-6.
3. If the projections use grid shift files, do we just check that they
use the same file, or do we compare their contents?
Seems not that easy after all. As a simple user I would expect that (at
least?) locations created using 'epsg:4326' would be easy to
compare/identify.
Nikos
We don't currently have any way to check whether two projections are
identical, and this isn't a trivial question. E.g.:
Interesting.
Why does it say
"data set and location projection appear to match"
when importing a file into GRASS?