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

[Glynn Clements]

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 at gclements.plus.com>