[CC'd to developers' list]
Rado Bonk wrote:
GRASS:~> g.setproj:
XY-location cannot be projected.
In that case, you'll have to edit the cellhd file manually to change
the projection to something else.
Question for developers: why is g.setproj paying any attention to the
current projection type?
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, 23 Nov 2004, Glynn Clements wrote:
[CC'd to developers' list]
Rado Bonk wrote:
GRASS:~> g.setproj:
XY-location cannot be projected.
In that case, you'll have to edit the cellhd file manually to change
the projection to something else.Question for developers: why is g.setproj paying any attention to the
current projection type?
I suspect it may be a historical artefact from when GRASS supported only
XY, UTM and LL and g.setproj was a 3rd-party module added by the Soil Conservation Service (who originally wrote v.proj and introduced PROJ into GRASS via Mapgen). The location would have already had its projection defined in the WIND file and g.setproj's original job was just to augment this by adding PROJ_INFO and PROJ_UNITS files (for use by the pj_* functions), not to change the projection of the location to something else.
So I think this original design philosophy of augmenting a location's projection description rather than overwriting it with a new one may explain the behaviour. But g.setproj is in such a mess I wouldn't like to have to change it. In 5.7 g.proj can be used to create a location (or overwrite the projection of an existing location) if you have a PROJ.4 or WKT projection description, an EPSG projection code or a georeferenced raster or vector file. Some day hopefully g.setproj can be done away with (when someone in the PROJ community produces a better database of the parameters required by each projection than is currently contained in lib/gis/geo_init.c).
Paul