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

[Paul Kelly]

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