[GRASS5] Even More on Projections

[Eric G . Miller]

On Thu, Sep 21, 2000 at 03:32:59PM -0500, Frank Warmerdam wrote:
> Folks, 
> 
[snip]
> 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'd say, make sure the data to be imported matches the current location.
If not, bail out with an *informative* error.  IMHO, all import programs
should check this (when possible).  I think r.in.doq is special because
the projection is assumed UTM.  Since GRASS doesn't seem to care much
about datums, I don't think it cares about NAD27 vs. NAD83 (which *does*
matter).  I think that program is maybe a little dated (as are several
of the import routines).

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

I'd still say bail out with an error.  Though I initially found
GRASS's insistence on all data in a location having the same coord.
sys/projection, I now find it somewhat convenient.  You know that all
the data is in projection xyz for a location a year later.  Perhaps in
the future GRASS can support changing locations without a restart.

BTW, here's my PROJ_INFO and PROJ_UNITS files for what we California's
might call the "Teale Albers" projection (after the Teale Data Center).
Note: It really should have a NAD27 (conus?) datum too. I guess having
a datum would obviate the 'ellps' in most cases.

$ cat PROJ_INFO 
 name: Albers Equal Area
 proj: aea
 ellps: clark66
 a: 6378206.4000000004
 es: 0.0067686580
 lat_0: 0.0000000000
 lat_1: 34.0000000000
 lat_2: 40.5000000000
 lon_0: -120.0000000000
 x_0: 0.0000000000
 y_0: -4000000.000 

$ cat PROJ_UNITS 
 unit: meter
 units: meters
 meters: 1.0
 

-- 
/bin/sh ~/.signature:
Command not found

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