Paul:
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.
thanks for the comments. One thing I worry about is that if you
change between the main A,B,C,D types the proj: 0,1,3,99 setting
in WIND and/or DEFAULT_WIND, PROJ_INFO, mapset WINDs, and raster
map cellhd files and vector map (?) files can become out of sync.
I know at least for raster maps if you try to use a raster map
who's cellhd proj: number does not match the WIND setting it exits
with a libgis error.
e.g. G__open_cell_old() and G__check_for_auto_masking() (there
MASK would silently not be used)
So maybe for that reason enforce no XY<->Lat/Lon<->UTM<->Other
changes by g.setproj. That does seem a bit silly for UTM<->Other,
but refusal to switch between polar, Cartesian, and unreferenced
coordinate systems is at least plausible.
hmm. If I open a UTM location, then run g.setproj to change it to a
Albers projection, the WIND files do not update, so existing maps
still display ok. v.info reports the new g.proj setting while r.info
and g.region report the old value stored in the map's cellhd file.
So as long as you don't edit any WIND or DEFAULT_WIND files it shouldn't
be left in a broken state, although weird things might happen when
you go to reproject maps(?).
thus g.setproj should stay restricted to changing things like map datums
and tweaking false eastings and scale factors, etc. ???
for stability reasons I'd reserve changes to such low-level things to
grass 7.
Hamish