[GRASS-dev] g.setproj from XY locn?

[Hamish]

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