[Bug] r.grow requires much more disk space than the size of the input raster

Open
  • Is something wrong?
#8,147 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c, python
Domain
cli, data-engineering

Research direction

The bug is in the r.grow module, whose source lives under raster/r.grow in the GRASS repository; the report names the euclidean metric and radius 2 as the trigger. Start by reading how the module allocates its temporary distance and output buffers for a raster of about 2.7 billion cells, then reproduce with a small raster and check temp file usage. Done means r.grow completes on the reported input with disk use comparable to the input.

Written by the indexing model from the issue text.

Description

bug

Describe the bug

When running r.grow with a radius of 2px, euclidean metric, on a 2,642,178 KB raster, my 39,375,716 KB of free space are not enough and the algorithm fails with No Space Left On Device.

Raster details :

 |   Type of Map:  raster               Number of Categories: 0               |
 |   Data Type:    CELL                 Semantic label: (none)                |
 |   Rows:         50123                                                      |
 |   Columns:      53967                                                      |
 |   Total Cells:  2704987941                                                 |
 |        Projection: RGF93 v1 / Lambert-93                                   |
 |            N: 6856084.75    S: 6831023.25   Res:   0.5                     |
 |            E:  656500.75    W:  629517.25   Res:   0.5                     |
 |   Range of data:    min = 1  max = 1                                       |
 |                                                                            |
 |   Data Description:                                                        |
 |    generated by r.in.gdal

To reproduce

  1. run r.grow input="raster", output="raster_grown", radius="2", old=1, new=1)

Same in QGIS using GRASS (except the processing temp file actually occupies all free space and I end up with 0 KB free) and Jupyter Lab using GRASS :

Image

Expected behavior

The processing runs its course and the resulting raster is produced with a size comparable to the input raster size.

System description

  • Operating System: Windows 11
  • GRASS version: 8.5.0 (64Bit)
  • Build date : 2026-06-12
  • Python 3.12.16
  • wxPython 4.2.5

Additional context

Input raster values are either 1 or NoData.

Dominant language
C
Stars
1.2k
Forks
447
Avg merge
1d 19h
Merged PRs (30d)
62

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OSGeo/grass

All issues in OSGeo/grass

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.