BTW: Maybe we should modify '-l' of g.region to work on WGS84 (like d.where)?
Or just advertise that the current datum is used? I am not sure what's
preferred.
Well if you don't know I don't think I'm very likely to know either!
Presumably the feature is there for a reason but as I don't know what
people use it for I wouldn't want to be the one to change it. Better to
keep things consistent unless there's a good reason for changing (there
was for d.where; it used the old coorcnv library and part of the
functionality worked only in UTM locations).
On Thu, Mar 04, 2004 at 05:10:33PM +0000, Paul Kelly wrote:
Markus Neteler wrote:
>
> BTW: Maybe we should modify '-l' of g.region to work on WGS84 (like d.where)?
> Or just advertise that the current datum is used? I am not sure what's
> preferred.
Well if you don't know I don't think I'm very likely to know either!
Presumably the feature is there for a reason but as I don't know what
people use it for I wouldn't want to be the one to change it.
I think that I implemented it to support myself in downloading satellite
data from the NASA data repository. They always want LatLong for project
areas. So I added -l, and g.region tells me immediately the current
coordinates in LatLong. Copy-paste and I'm done.
Better to
keep things consistent unless there's a good reason for changing (there
was for d.where; it used the old coorcnv library and part of the
functionality worked only in UTM locations).
So that's a vote to change g.region. I tend to agree, because a
reliable WGS84 output is better than a sort of undefined LatLong
output with current datum/ellipsoid.
Other opinions?
> > BTW: Maybe we should modify '-l' of g.region to work on WGS84
> > (like d.where)? Or just advertise that the current datum is used?
> > I am not sure what's preferred.
[...]
> Better to keep things consistent unless there's a good reason for
> changing
Yes.
> (there was for d.where; it used the old coorcnv library and part of
> the functionality worked only in UTM locations).
So that's a vote to change g.region. I tend to agree, because a
reliable WGS84 output is better than a sort of undefined LatLong
output with current datum/ellipsoid.
Other opinions?
d.where has
Flags:
-d Output lat/long in decimal degree
-l Output lat/long referenced to current ellipsoid
-w Output lat/long referenced to WGS84 ellipsoid using datum
transformation parameters defined in current location if available
[
note descriptions aren't very clear and could probably be improved..
-d is independent of datum/ellps choice;
-l should change to ellps/datum;
-w wording is awkward
the program will prompt you if you try and mix them improperly though.
]
g.region should match, I think all that means is adding a -w flag to
get a WGS84 version of -l. (I think the default action should be to use
the current ellps/datum)
?
Hamish
ps -
GRASS53> d.where -w
[click]
WGS84 Co-ordinates
EAST: NORTH: LON: LAT:
pj_transform() failed
cause: failed to load NAD27-83 correction file
ERROR: Error in pj_do_proj()