[GRASS5] More on Projections

Morten Hulden email at protected
Thu Sep 21 20:51:54 EDT 2000



On Thu, 21 Sep 2000, Frank Warmerdam wrote:

> A little more I need to know about projections:
> 
>  o If the proj number in a raster header, or the WIND/DEFAULT_WIND file is
>    99 (PROJECTION_OTHER) does that mean that the definition of the projection
>    can only be found in the PROJ_INFO file, and that it will be one of the
>    types other than state plane, utm, latlong or XY? 

Definition of projection is only found in the PROJ_INFO file. I assume
that the number (1, 2, 3, 99) at the top of the cellhd file (and WIND,
DEFAULT_WIND) originally was a way to identify the projection of the map
or region, but as more projections were added to grass later they all got
the the number 99. As a consequence you cannot see what projection a 99
map is made in. If you copy a map and its associated cellhd file to
another location in a different projection, you may not get an error when
trying to display or process it, but the result will certainly not be what
you expect.

>  o I was looking at the r.proj command to see how it gets the projection 
>    definition of the source raster.  It appears to depend on the PROJ_INFO 
>    file existing (via a call to G_get_projinfo()) even though this file 
>    does not seem to exist on most of the sample datasets on the GRASS Sample
>    Dataset page.  

I don't know this sample data, but it's probably in
XY-(non)projection. XY-locations do not have a PROJ_INFO file. 

> It seems to me that r.proj should fallback to looking at
>    the proj: code of the raster, or the projection definition in the WIND
>    file, but as far as I can tell it does not.

The WIND file does not contain projection info, it contains information on
the borders and the resolution. r.proj (and r.proj.new) uses
G_get_projinfo() to read in the parameteres from PROJ_INFO into a
memory structure for later use.


>    How should a GRASS program safely determine what the projection of a raster
>    is?  

Something like
 myprojkeys = G_get_projinfo(); 
 myprojname = G_find_key_value("proj", myprojkeys);

will give you the name of the projection of the current location. Other
parameters should be extracted too of course. See
src/libes/proj/get_proj.c for examples.

[snip]

> Currently I prepare a struct Cell_head, attempting to set the projection
> to match that of the source file if possible.  

I don't it's a good idea to try to change the projection of an existing
location (even though it's possible, e.g with g.setproj) because the
user's old data will be rendered useless if the original projection cannot
be restored afterwards. Or do you mean setting the projection of the just
output map? In that case, the approach is wrong, because in GRASS the
projection is a property of the location, which all maps in it will
inherit. The only place where you find that info is in PROJ_INFO.
Individual maps do not have separate projection definitions.

> Am I responsible for doing validation to ensure the projection of
> my new raster matches the location?  

Yes, unless you instruct the user that a new location matching the source
map must be created manually before attempting to import the map.

> 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?

Good idea, but it may be hard to accomplish, because there are so many
paramenters to check, and all of them must somehow be included in the
source file, and your program should be able to parse them out.

> 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


regards
Morten Hulden



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



More information about the grass-dev mailing list