On Mon, 25 May 2009, Hamish wrote:
Hamish:
g.setproj doesn't let you run it from a XY location.
is that really necessary?
it makes it hard to import unprojected imagery, reset to
known bounds with r.region, and then change into a lat/lon
location. note in that workflow the raster's cellhd/
file must be hacked to be proj: 3.
Glynn wrote:
You could probably merge the "case 0" with
PROJECTION_OTHER, so it prompts for the projection.
I don't think it's a problem to technically do it, I'm just
trying to figure out if there's any good reason for it being
the way it is.
To hazard a guess: originally all the projection information for a GRASS
location was contained within the WIND file. In the very beginning this
would have just been UTM zone details, then it was extended to handle
latitude/longitude, and then extended further to handle State Plane. When
support for using PROJ.4 for reprojections was hacked in (AFAIK from a
non-CERL source, and originally just for v.proj), it couldn't use the
projection information in the GRASS WIND files and instead required
new-style PROJ_INFO and PROJ_UNITS files to be added to the location,
augmenting and partially duplicating the information in the WIND file. I
suspect the original g.setproj might not have altered the
WIND/DEFAULT_WIND files at all, but simply created PROJ_INFO and
PROJ_UNITS files. So the idea was not that g.setproj could make an
unprojected location projected, but just that it would augment the
existing projection information with projection information in an extended
format. Thus it made no sense to run it on an XY location as there was no
existing projection to be augmented - and indeed if the original g.setproj
did not edit WIND files then it would have been impossible for it to
change the projection of a location as it can do now.
That's all just conjecture based on clues I've picked up in the projection
code over the years, but I suppose it might be possible to prove or
disprove it by digging into some old GRASS sources!
The issue of removing this restriction has come up loads of times but I
never liked the idea of doing it in case I broke something else, as the
g.setproj code is such a mess. But Glynn's suggestion sounds sensible so I
would say go for it in 6.5/7.0 and see if anything breaks.
Paul
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
