[GRASS-dev] change region

GRASS GIS GRASS GIS developer
1

Hi,

I define a new location ba EPSG-Code (32648). After this I want to set the extents with

g.region n=6681125.59

and I get the Error Invalid region. If I have only 6 numbers in front of the point, Grass except my changes.
Could it be a bug?

Best regards
Alex

2

Alexander Schulze wrote:

I define a new location ba EPSG-Code (32648). After this I want to set the extents with

    g.region n=6681125.59

and I get the Error Invalid region. If I have only 6 numbers in front of the point, Grass except my changes.
Could it be a bug?

What does "g.region -p" print?

Try setting the resolution as well; if the resolution is too small,
the number of rows/columns may overflow the range of a 32-bit signed
integer.

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

3

Alexander Schulze wrote:

I define a new location ba EPSG-Code (32648). After this I want to set
the extents with

    g.region n=6681125.59

and I get the Error Invalid region. If I have only 6 numbers in front
of the point, Grass except my changes. Could it be a bug?

It works for me in GRASS 6.2.1. (make a new location from the GUI
startup menu using EPSG number, then "g.region n=6681125.59".

Are you sure it isn't defined as a Lat/Lon location instead of UTM zone 48N?

what if you create the region using UTM instead of EPSG code? (create by
Projection Values)

Hamish

4

Hamish wrote:

> I define a new location ba EPSG-Code (32648). After this I want to set
> the extents with
>
> g.region n=6681125.59
>
> and I get the Error Invalid region. If I have only 6 numbers in front
> of the point, Grass except my changes. Could it be a bug?

It works for me in GRASS 6.2.1. (make a new location from the GUI
startup menu using EPSG number, then "g.region n=6681125.59".

Are you sure it isn't defined as a Lat/Lon location instead of UTM zone 48N?

what if you create the region using UTM instead of EPSG code? (create by
Projection Values)

FWIW, he replied privately, indicating that setting the resolution
solved the problem.

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