Opened 9 years ago

Closed 8 years ago

#2654 closed defect (invalid)

r.thin crashes

Reported by: pairmand Owned by: grass-dev@…
Priority: normal Milestone: 7.0.3
Component: Raster Version: 7.0.0
Keywords: r.thin Cc:
CPU: x86-64 Platform: MSWindows 7

Description

r.thin crashes (Windows message that GRASS 7 has stopped working).

The input was first imported from the attached Erdas Imagine file into a new location (EPSG:2193), then thinned using the following commands;

r.in.gdal input=D:\temp_work\temukaSub_rasterEdges.img output=rasterEdges --overwrite -e

r.thin --overwrite --quiet input=rasterEdges output=thinnedRaster iterations=200

If the If the extent is not set using -e on the import, then it fails with "Unable to find bounding box for lines" but doesn't crash.

I have tried the same on Linux machine and in that case the "crash" has a message: "Error writing temporary file".

It has identical to above if the extent has not been defined (earlier versions of GRASS seemed to handle this).

Attachments (2)

temukaSub_rasterEdges.img (192.0 KB ) - added by pairmand 9 years ago.
Erdas Imagine 8-bit image (binary edges) in NZTM projection
GrassCrash.JPG (42.3 KB ) - added by pairmand 9 years ago.
Screen shot of GRASS 7 crash

Download all attachments as: .zip

Change History (10)

by pairmand, 9 years ago

Attachment: temukaSub_rasterEdges.img added

Erdas Imagine 8-bit image (binary edges) in NZTM projection

comment:1 by neteler, 9 years ago

Please post here also the output of

g.region -p

Additionally, is there enough free space on the disk?

comment:2 by marisn, 9 years ago

I am somehow unable to reproduce described "crash". If it is a real crash not just a stop with error message, please, run r.thin from gdb and afterwards also under valgrind and provide obtained backtraces.

Be ware - there was a serious flaw in documentation - r.thin is thinning non-null cells instead of non-zero cells, as documentation states. It is necessary to run r.null setnull=0 on your imported data otherwise thinning is useless.

by pairmand, 9 years ago

Attachment: GrassCrash.JPG added

Screen shot of GRASS 7 crash

comment:3 by pairmand, 9 years ago

Thank you both for your help - I think it was actually multiple unrelated problems. If I create a new location/mapset then g.region -p produces;

g.region -p                                                                     
projection: 99 (Transverse Mercator)
zone:       0
datum:      nzgd2k
ellipsoid:  grs80
north:      1
south:      0
west:       0
east:       1
nsres:      1
ewres:      1
rows:       1
cols:       1
cells:      1
(Mon Apr 20 11:50:24 2015) Command finished (0 sec)

If I then import the Imagine file with extend region and repeat I get;

r.in.gdal input=D:\temp_work\temukaSub_rasterEdges.img output=temukaSub_rasterEdges -e
WARNING: Datum <NZGD2000_NTv2> not recognised by GRASS and no parameters found
Raster map <temukaSub_rasterEdges> created.
Region for the current mapset updated
r.in.gdal complete.
(Mon Apr 20 11:53:07 2015) Command finished (0 sec)                             
(Mon Apr 20 11:53:20 2015)                                                      
g.region -p                                                                     
projection: 99 (Transverse Mercator)
zone:       0
datum:      nzgd2k
ellipsoid:  grs80
north:      5117010
south:      0
west:       0
east:       1474010
nsres:      1
ewres:      1
rows:       5117010
cols:       1474010
cells:      7542523910100
(Mon Apr 20 11:53:20 2015) Command finished (0 sec)

That is, the map coordinates seem to be set to the north east corner but south, west, cols and rows are all incorrect. This appears to be a bug importing from the Imagine file using the gdal importer. If I try and thin at this point then the thin crashes - see screenshot. http://trac.osgeo.org/grass/attachment/ticket/2654/GrassCrash.JPG

However, if I use g.region to correct the above I get a result that looks good;

g.region raster=temukaSub_rasterEdges                                           
(Mon Apr 20 12:03:08 2015) Command finished (0 sec)                             
(Mon Apr 20 12:03:22 2015)                                                      
g.region -p                                                                     
projection: 99 (Transverse Mercator)
zone:       0
datum:      nzgd2k
ellipsoid:  grs80
north:      5117010
south:      5108000
west:       1463000
east:       1474010
nsres:      10
ewres:      10
rows:       901
cols:       1101
cells:      992001
(Mon Apr 20 12:03:22 2015) Command finished (0 sec)

At this point running r.thin still produces an error and only appears to have processed the middle section of the image.

...
Thinning not completed, consider to increase 'iterations' parameter.
Output map 901 rows X 1101 columns
Window 901 rows X 1101 columns
(Mon Apr 20 12:04:46 2015) Command finished (17 sec)

Setting 0 as null cells fixes that problem also;

r.null map=temukaSub_rasterEdges setnull=0                                      
(Mon Apr 20 12:06:49 2015) Command finished (0 sec)                             
(Mon Apr 20 12:07:20 2015)                                                      
r.thin --overwrite input=temukaSub_rasterEdges@canTest output=temukaThinned     
Raster map <temukaSub_rasterEdges@canTest> - 901 rows X 1101 columns
Bounding box:  l = 2, r = 1102, t = 2, b = 902
Pass number 1
Deleted 68577 pixels
Pass number 2
Deleted 2270 pixels
Pass number 3
Deleted 37 pixels
Pass number 4
Deleted 0 pixels
Thinning completed successfully.
Output map 901 rows X 1101 columns
Window 901 rows X 1101 columns
(Mon Apr 20 12:07:21 2015) Command finished (0 sec)

So I'm now a happy camper - but suggest there is a bug in the raster importer, in that it doesn't set the extent correctly, and the documentation of r.thin definitely needs to clarify that it is working on nulls not zeros.

Thanks again for your help. David

in reply to:  3 ; comment:4 by mlennert, 9 years ago

Replying to pairmand:

Thank you both for your help - I think it was actually multiple unrelated problems. If I create a new location/mapset then g.region -p produces;

g.region -p                                                                     
projection: 99 (Transverse Mercator)
zone:       0
datum:      nzgd2k
ellipsoid:  grs80
north:      1
south:      0
west:       0
east:       1
nsres:      1
ewres:      1
rows:       1
cols:       1
cells:      1
(Mon Apr 20 11:50:24 2015) Command finished (0 sec)

If I then import the Imagine file with extend region and repeat I get;

r.in.gdal input=D:\temp_work\temukaSub_rasterEdges.img output=temukaSub_rasterEdges -e
WARNING: Datum <NZGD2000_NTv2> not recognised by GRASS and no parameters found
Raster map <temukaSub_rasterEdges> created.
Region for the current mapset updated
r.in.gdal complete.
(Mon Apr 20 11:53:07 2015) Command finished (0 sec)                             
(Mon Apr 20 11:53:20 2015)                                                      
g.region -p                                                                     
projection: 99 (Transverse Mercator)
zone:       0
datum:      nzgd2k
ellipsoid:  grs80
north:      5117010
south:      0
west:       0
east:       1474010
nsres:      1
ewres:      1
rows:       5117010
cols:       1474010
cells:      7542523910100
(Mon Apr 20 11:53:20 2015) Command finished (0 sec)

That is, the map coordinates seem to be set to the north east corner but south, west, cols and rows are all incorrect. This appears to be a bug importing from the Imagine file using the gdal importer.

The man page of r.in.gdal says about the '-e' flag: "Extend region extents based on new dataset". It does not say: Set the computational region to the extents of the imported map. So, the behaviour is conform to what it announces: your region is extended so that it also englobes the imported map.

I think that r.thin should not crash if there are no null values, so this is a bug, but AFAICS there is no bug in r.in.gdal.

Moritz

in reply to:  4 ; comment:5 by marisn, 9 years ago

Replying to mlennert:

I think that r.thin should not crash if there are no null values, so this is a bug, but AFAICS there is no bug in r.in.gdal.

Moritz

I have been unable to reproduce crash on my Linux machine so far. As far as I could understand, the crash is not rising from no lines to thin (lack of null values) but from running out of memory / disk space due to enormous computational region.

I have updated documentation to match module behaviour in r65083 (0 vs null) and removed use of unused error_prefix in r65101

The error message "Error writing temporary file" indicates running out of disk space. It is not a crash. Unless someone manages to reproduce crash on Linux (and provide output of gdb and valgrind!), I would tend to close this issue as caused by too large computational region.

comment:6 by neteler, 9 years ago

Milestone: 7.0.17.0.2

Ticket retargeted after 7.0.1 milestone closed

comment:7 by neteler, 8 years ago

Milestone: 7.0.27.0.3

Ticket retargeted after milestone closed

in reply to:  5 comment:8 by neteler, 8 years ago

Resolution: invalid
Status: newclosed

Replying to marisn:

The error message "Error writing temporary file" indicates running out of disk space. It is not a crash. Unless someone manages to reproduce crash on Linux (and provide output of gdb and valgrind!), I would tend to close this issue as caused by too large computational region.

Done so for now.

Note: See TracTickets for help on using tickets.