[GRASS5] Even More on Projections

GRASS GRASS developer
,
1

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?

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.

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?

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?

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerda@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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

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@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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

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

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

3

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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

"Eric G . Miller" a écrit :

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

5

Hi all

Andreas Lange wrote:

Maybe Justin Hickey can comment on this from his experience of the new
login setup.

I do plan to work on creating a "switch locations on the fly feature".
My initial investigations seem to predict it is possible, but I remember
trying this with the old Xgrass and having some problems. Of course,
those problems could have been with Xgrass. If you can wait, I will be
trying to do it though.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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

6

Andreas Lange wrote:

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.

Andreas,

It hasn't been my experience that G_get_projinfo() returns defaults if
PROJ_INFO is missing. Are you sure that it does? I had proposed changing
G_get_projinfo() to generate defaults from the proj/zone settig in the
WIND file if there was no PROJ_INFO file, but I didn't get any feedback
(positive or negative) on this suggestion.

This would be instead of implmenting the G_get_location_coordsys() call.

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

As part of r.in.gdal I have implemented a projection comparison function
(though it isn't really complete) which currently just lives in with r.in.gdal,
but if folks think it is worthwhile, I would be happy to move it into libgis.a.

static int
G_compare_projections( struct Key_Value *proj_info1,
                       struct Key_Value *proj_units1,
                       struct Key_Value *proj_info2,
                       struct Key_Value *proj_units2 )

It returns TRUE if they appear to be the same, otherwise FALSE.

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
(?).

I have tentatively implemented a location making function in C, that takes
Cell_head, proj_info and proj_units as inputs to default the projection and
extents of a new projection. Currently this is just in r.in.gdal, but
I would like to move it to libgis.a if folks think it worthwhile.

int G__make_location(
    char *location_name,
    struct Cell_head *wind,
    struct Key_Value *proj_info,
    struct Key_Value *proj_units,
    FILE *report_file )

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerda@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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

Hi Frank, hi Grassprogrammers,

Frank Warmerdam wrote:

Andreas,

It hasn't been my experience that G_get_projinfo() returns defaults if
PROJ_INFO is missing. Are you sure that it does? I had proposed changing
G_get_projinfo() to generate defaults from the proj/zone settig in the
WIND file if there was no PROJ_INFO file, but I didn't get any feedback
(positive or negative) on this suggestion.

you are of cause right here. It was just wishful thinking on my side.
The call to G_get_projinfo() echoes that the file PROJ_INFO was not
found. But contrary the call to G_get_ellipsoid_parameters gives default
values (and the new functions for the datum support too).
G_database_projection_name() gets a name for the projection even if the
PROJ_INFO file is missing (from the WIND/DEFAULT_WIND file?).
I think that this all needs some work to be consistent. This should be
discussed again when grass 5.0 is released.

As part of r.in.gdal I have implemented a projection comparison function
(though it isn't really complete) which currently just lives in with r.in.gdal,
but if folks think it is worthwhile, I would be happy to move it into libgis.a.

static int
G_compare_projections( struct Key_Value *proj_info1,
                       struct Key_Value *proj_units1,
                       struct Key_Value *proj_info2,
                       struct Key_Value *proj_units2 )

It returns TRUE if they appear to be the same, otherwise FALSE.

Yes, i would vote for including in the gis library.
I think that we should discuss how we can manage projection and datum
conversion in one step (different from my approach with the coordinate
conversion library), so that the {v|s|r}.proj commands can use a single
function call for conversion (with proj4).
But all this requires some user input if datum conversion is really
needed.

Thanks for your patience,

cu,

Andreas

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

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