[GRASS-dev] type of parameter resolution in g.region vs r.proj

Hi,

Apparently, for unprojected reference systems, r.proj doesn’t accept the parameter resolution expressed in DD:MM:SS, but only in decimal degrees (at least for me, any other experience?), while for example g.region does accept this format. The type of the parameter resolution is float for r.proj and integer for g.region (as far as i can understand digging into the source code). My (probably naive) question is : Wouldn’t it make sense to adopt integer type also for r.proj?

Thanks for any pointers

Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-leo@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission.

Hi,

On Wed, Jul 2, 2014 at 6:05 PM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:

Hi,

Apparently, for unprojected reference systems, r.proj doesn't accept the
parameter resolution expressed in DD:MM:SS, but only in decimal degrees (at
least for me, any other experience?), while for example g.region does accept
this format. The type of the parameter resolution is float for r.proj and
integer for g.region (as far as i can understand digging into the source
code).

The reason is the use of G_scan_resolution () in g.region:
http://grass.osgeo.org/programming7/wind__scan_8c.html#a45410fd362f91e2c0a47e369e3fcaa5c

My (probably naive) question is : Wouldn't it make sense to adopt
integer type also for r.proj?

You mean you want both DD:MM:SS and decimal degrees support for
r.proj? To me it sounds reasonable.

Markus