[GRASS5] Even More on Projections

[Andreas Lange]

Hi Frank,

i will try to answer some of your questions, but i must admit that i am
not sure for some concepts in GRASS myself.

In GRASS 4.x the projection was defined within the raster header and/or
the WIND/DEFAULT_WIND files. In GRASS 5 the projection information is
mainly in the PROJ_INFO file, but for the projections supported in GRASS
4.x the WIND/DEFAULT_WIND will suffice. Functions that return values
from the PROJ_INFO file return default values if this file is missing. I
dont think that the library functions have any provisions for
disagreeing proj information in DEFAULT_WIND and cell header. 

In the current setup all data in one location is in the same projection
in the same map datum. 
I personally think that a unified setup (all info either in the
associated header file (for a future support of projection-on-the-fly)
or in a central file for the location) would be better, but that implies
changing the library and all modules. 

The G_get_location_coordsys function is a very good idea IMHO.  

Frank Warmerdam wrote:
> 
> Folks,
> 
> Getting sick of me yet?
> 
> Amoung other things, I am trying to write an r.in.gdal command that will
> allow import of GDAL supported raster formats into GRASS.  GDAL sometimes
> has a strong concept of the coordinate system of a raster (and sometimes
> does not).  How should I implement such a command to make it easy for
> a user to import a raster?
> 

no idea.

> Currently I prepare a struct Cell_head, attempting to set the projection
> to match that of the source file if possible.  I then call G_set_window()
> with that structure, and then G_open_raster_new(), and write the file.
> This seems to result in a cellhd file being created with the information
> I passed to G_set_window() whether the projection matches the location or
> not.  Am I responsible for doing validation to ensure the projection of
> my new raster matches the location?  Some commands (like r.in.dted) seem
> to check, while others (like r.in.doq) seem to do the same as r.in.gdal.
> 

I fear there is no general concept, some modules check if projections
match, other do not. I think you should always validate matching
projection. 

> If the coordinate system doesn't match the existing location I would like
> it easy for the user to create a new location with a coordinate system
> matching the source file.  Is this something that raster import programs
> ever do?  Can you point me to an example that does this?
> 

Tom Pointdexter wrote a script "mklocation.sh" to create the directories
for a new location. The raster modules IMHO do not create a new
location, but i remember a script that creates a new location, imports
the raster data and uses r.proj to transfer this to the current location
(?). 

> Finally, as a user how do I change my current location?  Do I need to exit
> out of grass and restart it specifying a new location?
> 

Yes, exiting and restarting with a new location. You may manage the
enviroment variables yourself to shift a running grass session to a new
location, but i don't know which side effects this has. 
Maybe Justin Hickey can comment on this from his experience of the new
login setup. 

I will send you some PROJ_INFO and PROJ_UNITS files by PM.

cu,

Andreas

> Best regards,
> 
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerda at home.com
> light and sound - activate the windows | http://members.home.com/warmerda
> and watch the world go round - Rush    | Geospatial Programmer for Rent
> 
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net



---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'