[GRASS-user] g.region Options Yield Different Values

GRASS GRASS user
1

   Please explain to me why g.region -l shows region corners outside the
coordinate values shown by g.region -p. Makes no sense to me when they are
both run from the same location/mapset:

GRASS 6.4.0svn (Oregon):/usr4/grassbase/Oregon > g.region -p
projection: 99 (Lambert Conformal Conic)
zone: 0
datum: nad83
ellipsoid: grs80
north: 46.15916
south: 41.933088
west: -124.719106
east: -116.644278
nsres: 4.226072
ewres: 8.074828
rows: 1
cols: 1
cells: 1
GRASS 6.4.0svn (Oregon):/usr4/grassbase/Oregon > g.region -l
north-west corner: long: 125:18:06.67543W lat: 41:38:42.416382N
north-east corner: long: 125:18:06.327366W lat: 41:38:42.431669N
south-east corner: long: 125:18:06.3167W lat: 41:38:42.29503N
south-west corner: long: 125:18:06.664764W lat: 41:38:42.279743N
center longitude: 125:18:06.496065W
center latitude: 41:38:42.355706N
rows: 1
cols: 1

Rich

2

Rich Shepard wrote:

   Please explain to me why g.region -l shows region corners outside the
coordinate values shown by g.region -p. Makes no sense to me when they are
both run from the same location/mapset:

GRASS 6.4.0svn (Oregon):/usr4/grassbase/Oregon > g.region -p
projection: 99 (Lambert Conformal Conic)
zone: 0
datum: nad83
ellipsoid: grs80
north: 46.15916
south: 41.933088
west: -124.719106
east: -116.644278
nsres: 4.226072
ewres: 8.074828
rows: 1
cols: 1
cells: 1
GRASS 6.4.0svn (Oregon):/usr4/grassbase/Oregon > g.region -l
north-west corner: long: 125:18:06.67543W lat: 41:38:42.416382N
north-east corner: long: 125:18:06.327366W lat: 41:38:42.431669N
south-east corner: long: 125:18:06.3167W lat: 41:38:42.29503N
south-west corner: long: 125:18:06.664764W lat: 41:38:42.279743N
center longitude: 125:18:06.496065W
center latitude: 41:38:42.355706N
rows: 1
cols: 1

Because g.region -p shows the cartographic coordinates in metres/feet
in the specified coordinate system (LCC, with the origin at
approximately 41:38:42N, 125:18:06W), while g.region -l shows the
coordinates converted to lat/lon.

The reason is almost certainly that lat/lon coordinates were used
where cartographic coordinates were required.

--
Glynn Clements <glynn@gclements.plus.com>

3

On Sat, 21 Nov 2009, Glynn Clements wrote:

Because g.region -p shows the cartographic coordinates in metres/feet in
the specified coordinate system (LCC, with the origin at approximately
41:38:42N, 125:18:06W), while g.region -l shows the coordinates converted
to lat/lon.

The reason is almost certainly that lat/lon coordinates were used
where cartographic coordinates were required.

Glynn,

   The origin of the Oregon LCC is 41.75N (which is about 41:38), but the
central meridian is -120.5W (or 120:30W). In any case, lat/long are the way
the boundaries are specified in the metadata. There are additional units in
m/ft (probably the latter since the metadata says units are in International
Feet).

   When I specify the bounds of a region and have only lat/long values, what
am I supposed to do? I don't see this covered in the book or the man pages
I've seen.

   I would like to get this right so all additional data can be properly imported
and make life easier.

Thanks,

Rich

4

Rich Shepard wrote:

> Because g.region -p shows the cartographic coordinates in metres/feet in
> the specified coordinate system (LCC, with the origin at approximately
> 41:38:42N, 125:18:06W), while g.region -l shows the coordinates converted
> to lat/lon.
>
> The reason is almost certainly that lat/lon coordinates were used
> where cartographic coordinates were required.

Glynn,

   The origin of the Oregon LCC is 41.75N (which is about 41:38), but the
central meridian is -120.5W (or 120:30W). In any case, lat/long are the way
the boundaries are specified in the metadata. There are additional units in
m/ft (probably the latter since the metadata says units are in International
Feet).

   When I specify the bounds of a region and have only lat/long values, what
am I supposed to do? I don't see this covered in the book or the man pages
I've seen.

It doesn't make any sense to specify lat/lon boundaries for projected
data, particularly for a non-cylindrical projection such as LCC.

A rectangle in the lat/lon coordinate space would project to an
annular sector in LCC (i.e. two straight but non-parallel edges for
the east and west and partial circles for north and south), while a
rectangle in LCC would be similarly distorted when projected to
lat/lon.

In particular, if you have *raster* data in an LCC projection, you
need to know its bounds in LCC, otherwise you don't really have any
data, just an array of numbers.

OTOH, if the raster data uses a lat/lon grid, it needs to be imported
into a lat/lon location. You can project it afterwards with r.proj.

If you have vector data, so long as you get the projection parameters
correct, you can set the bounds from the data once you have imported
it.

--
Glynn Clements <glynn@gclements.plus.com>

5

On Sun, 22 Nov 2009, Glynn Clements wrote:

It doesn't make any sense to specify lat/lon boundaries for projected
data, particularly for a non-cylindrical projection such as LCC.

Glynn,

   That's true. I've obviously erred when creating new locations and
importing .shp and .e00 files.

   I've used the wxPython GUI to define new locations and the mapset. When I
specify choosing the projection from the list and select LCC I'm asked to
enter the relevant projection parameters. I then specify NAD83 as the datum
and the Washington-Oregon adjustment. Finally, I'm asked if I want to enter
the default region's extent and resolution. This is where I enter the
lat/long coordinates I have.

   Perhaps it's this last step that I have wrong. Should I decline to enter
the extents and resolution and leave those to the information embedded in
the imput data?

   As I've written before it's been a very long time since I last used GRASS
and quite likely that I've mis-used the new GUI.

Thanks,

Rich

6

Rich Shepard wrote:

   That's true. I've obviously erred when creating new locations and
importing .shp and .e00 files.

   I've used the wxPython GUI to define new locations and the mapset. When I
specify choosing the projection from the list and select LCC I'm asked to
enter the relevant projection parameters. I then specify NAD83 as the datum
and the Washington-Oregon adjustment. Finally, I'm asked if I want to enter
the default region's extent and resolution. This is where I enter the
lat/long coordinates I have.

   Perhaps it's this last step that I have wrong.

Yes. If you create a projected location, you need to enter projected
coordinates.

Should I decline to enter
the extents and resolution and leave those to the information embedded in
the imput data?

I think that you may need to enter something here, but it doesn't have
to be correct, and you can change it later.

The current region is usually ignored when importing maps. Vector maps
will contain cartographic coordinates. Raster maps will either have
its bounds stored in metadata, or you will get clearly bogus bounds
and have to set the correct bounds manually with r.region afterwards.

If you have imported a vector map or a raster map with the correct
bounds, you can set the current and/or default region from the map.

--
Glynn Clements <glynn@gclements.plus.com>

7

On Mon, 23 Nov 2009, Glynn Clements wrote:

Yes. If you create a projected location, you need to enter projected
coordinates.

Glynn,

   And if they're available only as lat/long geographic coordinates ...?

I think that you may need to enter something here, but it doesn't have to
be correct, and you can change it later.

   OK.

The current region is usually ignored when importing maps. Vector maps
will contain cartographic coordinates. Raster maps will either have its
bounds stored in metadata, or you will get clearly bogus bounds and have
to set the correct bounds manually with r.region afterwards.

   I know that the .prj and .e00 files have the projection information and
cartographic coordinates so I use those. It's creating a new, empty location
that seems to be giving me the problems.

If you have imported a vector map or a raster map with the correct bounds,
you can set the current and/or default region from the map.

   True. And then I can identify the values, too.

Much appreciated,

Rich

8

Rich Shepard wrote:

> Yes. If you create a projected location, you need to enter projected
> coordinates.

Glynn,

   And if they're available only as lat/long geographic coordinates ...?

Create the location anyhow and set the region from a map once you've
imported one.

If for some reason you need suitable bounds before you've imported any
maps you can use use "m.proj -i ..." to convert lat-lon coordinates to
projected coordinates (but projecting the corners of a lat-lon
rectangle may be an underestimate; e.g. for LCC, the southernmost
point will typically be somewhere in the middle of the southern edge,
not one of the corners).

For a more accurate estimate, create a lat-lon location, set the
region, use v.in.region and v.split to create a sampled boundary,
re-project that to the LCC location with v.proj, and use
"g.region vect=..." to set the default region from the projected
boundary.

--
Glynn Clements <glynn@gclements.plus.com>

9

On Tue, 24 Nov 2009, Glynn Clements wrote:

Create the location anyhow and set the region from a map once you've
imported one.

If for some reason you need suitable bounds before you've imported any
maps you can use use "m.proj -i ..." to convert lat-lon coordinates to
projected coordinates (but projecting the corners of a lat-lon
rectangle may be an underestimate; e.g. for LCC, the southernmost
point will typically be somewhere in the middle of the southern edge,
not one of the corners).

For a more accurate estimate, create a lat-lon location, set the
region, use v.in.region and v.split to create a sampled boundary,
re-project that to the LCC location with v.proj, and use
"g.region vect=..." to set the default region from the projected
boundary.

Glynn,

   Thank you very much for the lesson. I'll make sure that the layers I need
for this current project are correct then start planning the model.

Much appreciated,

Rich

10

On Sun, 22 Nov 2009, Glynn Clements wrote:

In particular, if you have *raster* data in an LCC projection, you need to
know its bounds in LCC, otherwise you don't really have any data, just an
array of numbers.

   I want to re-do the layers so they're all correct. Starting with the DEM,
here's the information from the metadata file:

Spatial_Domain:
   Bounding_Coordinates:
     West_Bounding_Coordinate: -124.896200
     East_Bounding_Coordinate: -117.01801421
     North_Bounding_Coordinate: 46.14636144
     South_Bounding_Coordinate: 41.629424

Spatial_Reference_Information:
   Horizontal_Coordinate_System_Definition:
     Planar:
       Map_Projection:
         Map_Projection_Name: Lambert Conformal Conic
         Lambert_Conformal_Conic:
           Standard_Parallel: 43.000000
           Standard_Parallel: 45.500000
           Longitude_of_Central_Meridian: -120.500000
           Latitude_of_Projection_Origin: 41.750000
           False_Easting: 1312336.000000
           False_Northing: 0.000000
         Planar_Coordinate_Information:
           Planar_Coordinate_Encoding_Method: row and column
           Coordinate_Representation:
             Abscissa_Resolution: 32.828670
             Ordinate_Resolution: 32.828670
           Planar_Distance_Units: User_Defined_Unit
         Geodetic_Model:
           Horizontal_Datum_Name: North American Datum of 1983
           Ellipsoid_Name: Geodetic Reference System 80
           Semi-major_Axis: 6378137.000000
           Denominator_of_Flattening_Ratio: 298.257222

   If I correctly understand what you wrote above, I use the projection
information when importing the data, but leave the bounds undefined. Once
the import is completed I can then run 'g.region rast=elevation10' to set
the bounds in appropriate units. Is this correct?

Rich

11

On Tue, 24 Nov 2009, Rich Shepard wrote:

If I correctly understand what you wrote above, I use the projection
information when importing the data, but leave the bounds undefined. Once
the import is completed I can then run 'g.region rast=elevation10' to set
the bounds in appropriate units.

   This is working very well. Only with the US Census TIGER street layer do I
have lat/long values in the result of 'g.region vect=streets'. I'll
reproject that into LCC and all layers should then be consistent.

Thanks,

Rich