Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Markus Metz]

On Mon, Apr 16, 2018 at 6:46 PM, Markus Neteler  wrote:
>
> On Mon, Apr 16, 2018 at 11:39 AM, Markus Metz
>  wrote:
> > On Mon, Apr 16, 2018 at 11:35 AM, Martin Landa 
> > wrote:
> >> 2018-04-16 11:32 GMT+02:00 Markus Metz :
> >> > fixed in trunk r72620 and relbr74 r72621. That was a rather serious
bug
> >> > in
> >> > r.in.gdal -r, therefore IMHO a new GRASS 7.4 release should go out
asap.
> >>
> >> good timing, we are close to RC1 [1]. Ma
> >>
> >> [1] https://trac.osgeo.org/grass/milestone/7.4.1
> >
> > Mabe a new bugfix release for 7.2 should also go out.
>
> Why 7.2? I thought is is not affected...?

You are right, this affects only r.in.gdal, and only in G7.4+. G7.2 is not
affected because there is no -r flag for r.in.gdal (see my previous post).

Markus M
>
> markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Makefile for mixed Python & C module

[Maris Nartiss]

Hi devs,
during my free time I have been working on a Python module, but its
performance with PyGRASS was miserable. I managed to improve
performance by moving some loops to C and calling them from Python
with ctypes. Only thing I can not figure out is the Makefile.

How should a Makefile for hybrid module look like? Code is organized
in a simple fashion with two files:
i.module.py
get_data.c

Will it be possible to ship such code as an addon?

Thanks,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Markus Neteler]

On Mon, Apr 16, 2018 at 11:39 AM, Markus Metz
 wrote:
> On Mon, Apr 16, 2018 at 11:35 AM, Martin Landa 
> wrote:
>> 2018-04-16 11:32 GMT+02:00 Markus Metz :
>> > fixed in trunk r72620 and relbr74 r72621. That was a rather serious bug
>> > in
>> > r.in.gdal -r, therefore IMHO a new GRASS 7.4 release should go out asap.
>>
>> good timing, we are close to RC1 [1]. Ma
>>
>> [1] https://trac.osgeo.org/grass/milestone/7.4.1
>
> Mabe a new bugfix release for 7.2 should also go out.

Why 7.2? I thought is is not affected...?

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Markus Metz]

On Mon, Apr 16, 2018 at 5:23 PM, Markus Neteler  wrote:
>
> On Mon, Apr 16, 2018 at 11:39 AM, Markus Metz
>  wrote:
> > On Mon, Apr 16, 2018 at 11:35 AM, Martin Landa 
> > wrote:
> >>
> >> Hi,
> >>
> >> 2018-04-16 11:32 GMT+02:00 Markus Metz :
> >> > fixed in trunk r72620 and relbr74 r72621. That was a rather serious
bug
> >> > in
> >> > r.in.gdal -r, therefore IMHO a new GRASS 7.4 release should go out
asap.
> >>
> >> good timing, we are close to RC1 [1]. Ma
> >>
> >> [1] https://trac.osgeo.org/grass/milestone/7.4.1
> >
> > Mabe a new bugfix release for 7.2 should also go out.
>
> Does the bug(fix) affect all imports made with -r or only some under
> "special" (whatever that is) conditions?

this affects only r.in.gdal, and only in G7.4+. G7.2 is not affected
because there is no -r flag for r.in.gdal.

Markus M
>
> markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Markus Neteler]

On Mon, Apr 16, 2018 at 11:39 AM, Markus Metz
 wrote:
> On Mon, Apr 16, 2018 at 11:35 AM, Martin Landa 
> wrote:
>>
>> Hi,
>>
>> 2018-04-16 11:32 GMT+02:00 Markus Metz :
>> > fixed in trunk r72620 and relbr74 r72621. That was a rather serious bug
>> > in
>> > r.in.gdal -r, therefore IMHO a new GRASS 7.4 release should go out asap.
>>
>> good timing, we are close to RC1 [1]. Ma
>>
>> [1] https://trac.osgeo.org/grass/milestone/7.4.1
>
> Mabe a new bugfix release for 7.2 should also go out.

Does the bug(fix) affect all imports made with -r or only some under
"special" (whatever that is) conditions?

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Impossible to kill r.in.gdal

[Luca Delucchi]

Hi devs,

I'm importing raster dataset with r.in.gdal but I have a problem
because the processes seems to died but they didn't stop and I'm not
neither able to kill them, any idea?

 r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199705.nc
output=T_2M_1997_05 memory=4048 -o
No projection information available
Over-riding projection check
Importing 744 raster bands...
Importing raster map ...
 100%
^C^C^C^C^C^C^C^C^C^C^C^C^Z
^C
^C^C^C^C^Z^C
^Z^Z


ps aux | grep r.in.gdal
lucadelu  9486  0.0  0.1 415908 37880 ?DApr12   0:00
r.in.gdal 
input=NETCDF:/mnt/sas1/cosmorea6/converted/RELHUM_2M/RELHUM_2M_199901.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0
output=RELHUM_2M_1999_01 -o --q
lucadelu  9493  0.0  0.1 417752 39528 pts/3DApr12   0:00
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199801.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0 output=T_2M_1998_01
-o --q
lucadelu 16182  0.0  0.1 415908 37056 ?DApr13   0:00
r.in.gdal 
input=NETCDF:/mnt/sas1/cosmorea6/converted/RELHUM_2M/RELHUM_2M_200101.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0
output=RELHUM_2M_2001_01 -o --q
lucadelu 16185  0.0  0.1 417752 39288 pts/3DApr13   0:00
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199701.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0 output=T_2M_1997_01
-o --q
lucadelu 43603  0.0  0.1 419412 40044 pts/3D+   13:25   0:00
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199705.nc
output=T_2M_1997_05 memory=4048 -o
lucadelu 44279  0.0  0.0  12784   932 pts/0S+   15:23   0:00 grep r.in.gdal
lucadelu 47014  0.0  1.9 1004312 625336 ?  DApr05   0:52
r.in.gdal 
input=NETCDF:/mnt/sas1/cosmorea6/converted/RELHUM_2M/RELHUM_2M_199701.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0
output=RELHUM_2M_1997_01 -o --q
lucadelu 47540  0.0  0.9 682468 304164 pts/3   DApr05   0:20
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199705.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0 output=T_2M_1997_05
-o --q

killall -9 r.in.gdal

ps aux | grep r.in.gdal
lucadelu  9486  0.0  0.1 415908 37880 ?DApr12   0:00
r.in.gdal 
input=NETCDF:/mnt/sas1/cosmorea6/converted/RELHUM_2M/RELHUM_2M_199901.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0
output=RELHUM_2M_1999_01 -o --q
lucadelu  9493  0.0  0.1 417752 39528 pts/3DApr12   0:00
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199801.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0 output=T_2M_1998_01
-o --q
lucadelu 16182  0.0  0.1 415908 37056 ?DApr13   0:00
r.in.gdal 
input=NETCDF:/mnt/sas1/cosmorea6/converted/RELHUM_2M/RELHUM_2M_200101.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0
output=RELHUM_2M_2001_01 -o --q
lucadelu 16185  0.0  0.1 417752 39288 pts/3DApr13   0:00
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199701.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0 output=T_2M_1997_01
-o --q
lucadelu 43603  0.0  0.1 419412 40044 pts/3D+   13:25   0:00
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199705.nc
output=T_2M_1997_05 memory=4048 -o
lucadelu 44287  0.0  0.0  12784   944 pts/0S+   15:24   0:00 grep r.in.gdal
lucadelu 47014  0.0  1.9 1004312 625336 ?  DApr05   0:52
r.in.gdal 
input=NETCDF:/mnt/sas1/cosmorea6/converted/RELHUM_2M/RELHUM_2M_199701.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0
output=RELHUM_2M_1997_01 -o --q
lucadelu 47540  0.0  0.9 682468 304164 pts/3   DApr05   0:20
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199705.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0 output=T_2M_1997_05
-o --q

kill -9 9486 9493 16182 16185 43603 47014 47540

ps aux | grep r.in.gdal
lucadelu  9486  0.0  0.1 415908 37880 ?DApr12   0:00
r.in.gdal 
input=NETCDF:/mnt/sas1/cosmorea6/converted/RELHUM_2M/RELHUM_2M_199901.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0
output=RELHUM_2M_1999_01 -o --q
lucadelu  9493  0.0  0.1 417752 39528 pts/3DApr12   0:00
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199801.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0 output=T_2M_1998_01
-o --q
lucadelu 16182  0.0  0.1 415908 37056 ?DApr13   0:00
r.in.gdal 
input=NETCDF:/mnt/sas1/cosmorea6/converted/RELHUM_2M/RELHUM_2M_200101.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0
output=RELHUM_2M_2001_01 -o --q
lucadelu 16185  0.0  0.1 417752 39288 pts/3DApr13   0:00
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199701.nc
memory=6072 title=COSMO REA6 offset=0 num_digits=0 output=T_2M_1997_01
-o --q
lucadelu 43603  0.0  0.1 419412 40044 pts/3D+   13:25   0:00
r.in.gdal input=NETCDF:/mnt/sas1/cosmorea6/converted/T_2M/T_2M_199705.nc
output=T_2M_1997_05 memory=4048 -o
lucadelu 44303  0.0  0.0  12784   988 pts/0S+   15:25   0:00 grep r.in.gdal
lucadelu 47014  0.0  1.9 1004312 625336 ?   

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Nikos Alexandris]

* Markus Metz  [2018-04-16 14:00:24 +0200]:


On Mon, Apr 16, 2018 at 12:28 PM, Nikos Alexandris 
wrote:


* Markus Neteler  [2018-04-15 22:49:09 +0200]:


On Sun, Apr 15, 2018 at 9:46 PM, Markus Neteler 

wrote:


On Sun, Apr 15, 2018 at 8:48 PM, Veronica Andreo 

wrote:


Hi devs,

I just found something odd. I have a CHIRPS tif for Africa [0], but I

would

only need to import Ghana, so I used r.in.gdal -r. However when I

visualize

the data, most of it is nodata, while the full map of Africa has data

all

over the continent. Then, I tried also with r.import extent=region.

Same

result. The only thing providing what I expected to be the right

result (a

subset from the full map) is importing the whole map and then using
r.mapcalc to clip (i need the space in my hard disk)



trying harder I can reproduce the issue (of course not NULL related).

So, I have no clue right now why it behaves differently.



Hi,

no intention to add noise. There is something weird, here too.

# first things first
grass -c /geo/geodata/examples/chirps-v2.0.2018.01.01.tif

/geo/grassdb/onsight/chirps


# importing the whole map looks visually ok
r.in.gdal input=/geo/geodata/examples/chirps-v2.0.2018.01.01.tif

output=chirps_v2


# then, using the following box coordinates for Ghana from
# https://en.wikipedia.org/wiki/User%3aThe_Anome/country_bounding_boxes
g.region w=-4.000 e=4.733 n=20.000 s=11.167 -p


This bbox is north of Ghana, not Ghana.



# to draw the box on-display
v.in.region output=ghana_box

# and doing a partial import
r.in.gdal -r input=/geo/geodata/examples/chirps-v2.0.2018.01.01.tif

output=chirps_v2_subset


Regardless whether the box figures are not correct, while the imported
portion is, indeed, a box fraction of the whole map, it isn't, visually
the "right" part. It appears as a part from the coast has been imported.


Apparently you did not update your local copy of trunk or relbr74, see my
previous post.

Markus M



Early test performed with GRASS 7.5.svn (2018), libgis Revision: 72327,
libgis Date: 2018-03-06 12:12:44 +0100 (Tue, 06 Mar 2018).

Comfirmed, buggy behaviour is away using latest trunk.

Nikos


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Markus Metz]

On Mon, Apr 16, 2018 at 12:28 PM, Nikos Alexandris 
wrote:
>
> * Markus Neteler  [2018-04-15 22:49:09 +0200]:
>
>> On Sun, Apr 15, 2018 at 9:46 PM, Markus Neteler 
wrote:
>>>
>>> On Sun, Apr 15, 2018 at 8:48 PM, Veronica Andreo 
wrote:

 Hi devs,

 I just found something odd. I have a CHIRPS tif for Africa [0], but I
would
 only need to import Ghana, so I used r.in.gdal -r. However when I
visualize
 the data, most of it is nodata, while the full map of Africa has data
all
 over the continent. Then, I tried also with r.import extent=region.
Same
 result. The only thing providing what I expected to be the right
result (a
 subset from the full map) is importing the whole map and then using
 r.mapcalc to clip (i need the space in my hard disk)
>>
>>
>> trying harder I can reproduce the issue (of course not NULL related).
>>
>> So, I have no clue right now why it behaves differently.
>
>
> Hi,
>
> no intention to add noise. There is something weird, here too.
>
> # first things first
> grass -c /geo/geodata/examples/chirps-v2.0.2018.01.01.tif
/geo/grassdb/onsight/chirps
>
> # importing the whole map looks visually ok
> r.in.gdal input=/geo/geodata/examples/chirps-v2.0.2018.01.01.tif
output=chirps_v2
>
> # then, using the following box coordinates for Ghana from
> # https://en.wikipedia.org/wiki/User%3aThe_Anome/country_bounding_boxes
> g.region w=-4.000 e=4.733 n=20.000 s=11.167 -p

This bbox is north of Ghana, not Ghana.

>
> # to draw the box on-display
> v.in.region output=ghana_box
>
> # and doing a partial import
> r.in.gdal -r input=/geo/geodata/examples/chirps-v2.0.2018.01.01.tif
output=chirps_v2_subset
>
> Regardless whether the box figures are not correct, while the imported
> portion is, indeed, a box fraction of the whole map, it isn't, visually
> the "right" part. It appears as a part from the coast has been imported.

Apparently you did not update your local copy of trunk or relbr74, see my
previous post.

Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Nikos Alexandris]

* Markus Neteler  [2018-04-15 22:49:09 +0200]:


On Sun, Apr 15, 2018 at 9:46 PM, Markus Neteler  wrote:

On Sun, Apr 15, 2018 at 8:48 PM, Veronica Andreo  wrote:

Hi devs,

I just found something odd. I have a CHIRPS tif for Africa [0], but I would
only need to import Ghana, so I used r.in.gdal -r. However when I visualize
the data, most of it is nodata, while the full map of Africa has data all
over the continent. Then, I tried also with r.import extent=region. Same
result. The only thing providing what I expected to be the right result (a
subset from the full map) is importing the whole map and then using
r.mapcalc to clip (i need the space in my hard disk)


trying harder I can reproduce the issue (of course not NULL related).

So, I have no clue right now why it behaves differently.


Hi,

no intention to add noise. There is something weird, here too.

# first things first
grass -c /geo/geodata/examples/chirps-v2.0.2018.01.01.tif 
/geo/grassdb/onsight/chirps

# importing the whole map looks visually ok
r.in.gdal input=/geo/geodata/examples/chirps-v2.0.2018.01.01.tif 
output=chirps_v2

# then, using the following box coordinates for Ghana from
# https://en.wikipedia.org/wiki/User%3aThe_Anome/country_bounding_boxes
g.region w=-4.000 e=4.733 n=20.000 s=11.167 -p

# to draw the box on-display
v.in.region output=ghana_box

# and doing a partial import
r.in.gdal -r input=/geo/geodata/examples/chirps-v2.0.2018.01.01.tif 
output=chirps_v2_subset

Regardless whether the box figures are not correct, while the imported
portion is, indeed, a box fraction of the whole map, it isn't, visually
the "right" part. It appears as a part from the coast has been imported.

I am double-checking the steps I followed, I always get the same.

?

Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Markus Metz]

On Mon, Apr 16, 2018 at 11:35 AM, Martin Landa 
wrote:
>
> Hi,
>
> 2018-04-16 11:32 GMT+02:00 Markus Metz :
> > fixed in trunk r72620 and relbr74 r72621. That was a rather serious bug
in
> > r.in.gdal -r, therefore IMHO a new GRASS 7.4 release should go out asap.
>
> good timing, we are close to RC1 [1]. Ma
>
> [1] https://trac.osgeo.org/grass/milestone/7.4.1

Mabe a new bugfix release for 7.2 should also go out.

Markus M
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Martin Landa]

Hi,

2018-04-16 11:32 GMT+02:00 Markus Metz :
> fixed in trunk r72620 and relbr74 r72621. That was a rather serious bug in
> r.in.gdal -r, therefore IMHO a new GRASS 7.4 release should go out asap.

good timing, we are close to RC1 [1]. Ma

[1] https://trac.osgeo.org/grass/milestone/7.4.1

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

[Markus Metz]

On Sun, Apr 15, 2018 at 10:49 PM, Markus Neteler  wrote:
>
> On Sun, Apr 15, 2018 at 9:46 PM, Markus Neteler  wrote:
> > On Sun, Apr 15, 2018 at 8:48 PM, Veronica Andreo 
wrote:
> >> Hi devs,
> >>
> >> I just found something odd. I have a CHIRPS tif for Africa [0], but I
would
> >> only need to import Ghana, so I used r.in.gdal -r. However when I
visualize
> >> the data, most of it is nodata, while the full map of Africa has data
all
> >> over the continent. Then, I tried also with r.import extent=region.
Same
> >> result. The only thing providing what I expected to be the right
result (a
> >> subset from the full map) is importing the whole map and then using
> >> r.mapcalc to clip (i need the space in my hard disk)
>
> trying harder I can reproduce the issue (of course not NULL related).
>
> So, I have no clue right now why it behaves differently.

fixed in trunk r72620 and relbr74 r72621. That was a rather serious bug in
r.in.gdal -r, therefore IMHO a new GRASS 7.4 release should go out asap.

Markus M

>
> markusN
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev