[GRASS-dev] Re: [GRASS-user] Get current location projection in a Python Script

Glynn_Clements1 · May 31, 2010, 1:50am

[CC to grass-dev]

Nikos Alexandris wrote:

    # faster/ easier way: use of the "grass.region()" function
    rows = int(grass.region()['rows'])
    cols = int(grass.region()['cols'])

In 7.0, these fields are already integers; r40555 should be
backported.

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

neteler · May 31, 2010, 6:03am

On Mon, May 31, 2010 at 3:50 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

[CC to grass-dev]

Nikos Alexandris wrote:
\# faster/ easier way: use of the &quot;grass\.region\(\)&quot; function
rows = int\(grass\.region\(\)\[&#39;rows&#39;\]\)
cols = int\(grass\.region\(\)\[&#39;cols&#39;\]\)
In 7.0, these fields are already integers; r40555 should be
backported.

AFAIK it has been backported some time ago.

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/python/core.py#L503

Markus

Glynn_Clements1 · June 1, 2010, 3:46am

Markus Neteler wrote:

>> # faster/ easier way: use of the "grass.region()" function
>> rows = int(grass.region()['rows'])
>> cols = int(grass.region()['cols'])
>
> In 7.0, these fields are already integers; r40555 should be
> backported.

AFAIK it has been backported some time ago.

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/python/core.py#L503

Okay; change that to "I should 'svn update' the other branches more
often", then

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

Nikos_Alexandris1 · June 27, 2010, 7:56pm

On Tuesday 01 of June 2010 05:46:22 Glynn Clements wrote:

Markus Neteler wrote:
> >> # faster/ easier way: use of the "grass.region()" function
> >> rows = int(grass.region()['rows'])
> >> cols = int(grass.region()['cols'])
> >
> > In 7.0, these fields are already integers; r40555 should be
> > backported.
>
> AFAIK it has been backported some time ago.
>
> http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/
> python/core.py#L503

Okay; change that to "I should 'svn update' the other branches more
often", then

This means it should be like:

rows = grass.region()['rows']
cols = grass.region()['cols']

Right?

Nikos

Glynn_Clements1 · June 27, 2010, 11:58pm

Nikos Alexandris wrote:

> > >> # faster/ easier way: use of the "grass.region()" function
> > >> rows = int(grass.region()['rows'])
> > >> cols = int(grass.region()['cols'])
> > >
> > > In 7.0, these fields are already integers; r40555 should be
> > > backported.
> >
> > AFAIK it has been backported some time ago.
> >
> > http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/
> > python/core.py#L503
>
> Okay; change that to "I should 'svn update' the other branches more
> often", then

This means it should be like:

rows = grass.region()['rows']
cols = grass.region()['cols']

Right?

Right; although you should store the result of grass.region() to avoid
redundant g.region commands, i.e.:

  rgn = grass.region()
  rows = rgn['rows']
  cols = rgn['cols']

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

Nikos_Alexandris1 · June 28, 2010, 2:31am

Nikos Alexandris wrote:

> > > >> # faster/ easier way: use of the "grass.region()" function
> > > >> rows = int(grass.region()['rows'])
> > > >> cols = int(grass.region()['cols'])
> > > >
> > > > In 7.0, these fields are already integers; r40555 should be
> > > > backported.
> > >
> > > AFAIK it has been backported some time ago.
> > >
> > > http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/
> > > lib/ python/core.py#L503
> >
> > Okay; change that to "I should 'svn update' the other branches more
> > often", then
>
> This means it should be like:
>
> rows = grass.region()['rows']
> cols = grass.region()['cols']
>
> Right?

Glynn:

Right; although you should store the result of grass.region() to avoid
redundant g.region commands, i.e.:

  rgn = grass.region()
  rows = rgn['rows']
  cols = rgn['cols']

Thank you Glynn, Nikos

Nikos_Alexandris1 · July 21, 2010, 2:39pm

Nikos Alexandris wrote:

> > > >> rows = int(grass.region()['rows'])
> > > >> cols = int(grass.region()['cols'])

Glynn:

> > > > In 7.0, these fields are already integers; r40555 should be
> > > > backported.

Markus:

> > > AFAIK it has been backported some time ago.
> > > http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/
> > > lib/ python/core.py#L503

Glynn:

> > Okay; change that to "I should 'svn update' the other branches more
> > often", then

Nikos:

> This means it should be like:
>
> rows = grass.region()['rows']
> cols = grass.region()['cols']
>
> Right?

Glynn Clements wrote:

Right; although you should store the result of grass.region() to avoid
redundant g.region commands, i.e.:

  rgn = grass.region()
  rows = rgn['rows']
  cols = rgn['cols']

Is python's "int()" truncating or rounding up values? The question came to me
while thinking of r.mapcalc's respective functions ( i.e. "int() != round()" )

Nikos

Glynn_Clements1 · July 22, 2010, 6:35am

Nikos Alexandris wrote:

Nikos Alexandris wrote:
> > > > >> rows = int(grass.region()['rows'])
> > > > >> cols = int(grass.region()['cols'])

Is python's "int()" truncating or rounding up values? The question came to me
while thinking of r.mapcalc's respective functions ( i.e. "int() != round()" )

In this case, neither; it's just converting strings to integers. The
rows and cols values in the g.region output will always be integers.

If you pass a floating-point value to int(), it will be truncated
(i.e. rounded towards zero):

  > int(1.9)
  1
  > int(-1.9)
  -1

If you pass a string containing a decimal point to int(), it will
raise an exception:

  > int("1.9")
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ValueError: invalid literal for int() with base 10: '1.9'

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

Nikos_Alexandris1 · July 22, 2010, 7:44am

Nikos Alexandris wrote:

> > > > > >> rows = int(grass.region()['rows'])
> > > > > >> cols = int(grass.region()['cols'])
>
> Is python's "int()" truncating or rounding up values? The question came
> to me while thinking of r.mapcalc's respective functions ( i.e. "int()
> != round()" )

Glynn Clements wrote:

In this case, neither;

it's just converting strings to integers. The
rows and cols values in the g.region output will always be integers.

Right... needles question (=I need to rest a bit).

If you pass a floating-point value to int(), it will be truncated

(i.e. rounded towards zero):
> int(1.9)
1

  > int(-1.9)
  -1

If you pass a string containing a decimal point to int(), it will
raise an exception:
  > int("1.9")

  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ValueError: invalid literal for int() with base 10: '1.9'

Thanks for details, Nikos