[GRASS-user] G_malloc errors in i.segment

[Paul Shapley]

Hi Marcus,

Thanks again for your patience with this issue. It seems that whatever i
set in the memory of 'i.segment' to it throws up the same 'G_malloc' error
with the same 3 gb shortfall. I had another idea which is to make a smaller
subset image (but if i do this) will the new subset of 'id' segments be
applicable if applied to the entire image. For example if a value of '5134'
represents 'peat' could i use 'r.mapcalc' to query the entire image for
those values of '5134'. Supervised and Unsupervised Classification would
not yield the differences in the landscape i'm looking for which
'i.segment' succeeds.

Thanks,

Paul Shapley

On 21 June 2018 at 08:52, Markus Metz <markus.metz.giswork at gmail.com> wrote:

> [please keep it in the list]
>
> On Thu, Jun 21, 2018 at 9:12 AM, Paul Shapley <p.shapley at gmail.com> wrote:
> >
> > Thank you Markus...here are the results of g.region -p and r.info
> >
> > g.region -p
>
> > projection: 99 (OSGB 1936 / British National Grid)
> > zone:       0
> > datum:      osgb36
> > ellipsoid:  airy
> > north:      242815
> > south:      200862.25
> > west:       263134.25
> > east:       298833.75
> > nsres:      0.25
> > ewres:      0.25
> > rows:       167811
> > cols:       142798
> > cells:      23963075178
> > (Thu Jun 21 08:03:51 2018) Command finished (0 sec)
> >
> > (Thu Jun 21 08:08:02 2018)
>
> > r.info map=APGB_aerial_1.1 at PERMANENT
>
> >  +----------------------------------------------------------
> ------------------+
> >  | Map:      APGB_aerial_1.1 at PERMANENT      Date: Tue May 29 09:11:31
> 2018    |
> >  | Mapset:   PERMANENT                      Login of Creator:
> administrator   |
> >  | Location: TempLocation
>       |
> >  | DataBase: C:\
>      |
> >  | Title:    APGB_aerial_1.1
>      |
> >  | Timestamp: none
>      |
> >  |----------------------------------------------------------
> ------------------|
> >  |
>      |
> >  |   Type of Map:  raster               Number of Categories: 0
>       |
> >  |   Data Type:    CELL
>       |
> >  |   Rows:         167811
>       |
> >  |   Columns:      142798
>       |
> >  |   Total Cells:  23963075178
>      |
> >  |        Projection: OSGB 1936 / British National Grid
>       |
> >  |            N:     242815    S:  200862.25   Res:  0.25
>       |
> >  |            E:  298833.75    W:  263134.25   Res:  0.25
>       |
> >  |   Range of data:    min = 0  max = 255
>       |
> >  |
>      |
> >  |   Data Description:
>      |
> >  |    generated by r.in.gdal
>      |
> >  |
>      |
> >  |   Comments:
>      |
> >  |    r.in.gdal -o -k input="J:\Spatial Data\Aerial\APGB_received_20180416\
>   |
> >  |    \source\RGB_25cm\output\test\JPEG.png" output="APGB_aerial_1"
> memory\   |
> >  |    =300 offset=0 num_digits=0
>      |
> >  |
>      |
> >  +----------------------------------------------------------
> ------------------+
> > (Thu Jun 21 08:08:02 2018) Command finished (0 sec)
>
> OK, so you really have a group of rasters with 24 billion cells. Still, do
> you really need to run i.segment on the full extents with such a high
> resolution? If yes, try i.segment with memory=25000. Even if the system has
> more RAM, the operating system and any other programs also need some RAM,
> therefore it is safer to not use all free memory. Be aware that i.segment
> will take a long time (several days) to process such a large region.
>
> >
> > Should the output image from 'r.in.gdal' have had more memory allocated
> than the 300mb?
>
> The memory option of r.in.gdal applies to the input image, not the output
> image. Sometimes more memory can help, sometimes it does not have any
> effect. However, it does not affect subsequent processing steps.
>
> Markus M
>
> >
> > Thanks again Markus...I appreciate your help.
> >
> > Paul Shapley
> >
> >
> >
> >
> > On 20 June 2018 at 16:15, Markus Metz <markus.metz.giswork at gmail.com>
> wrote:
> >>
> >>
> >>
> >> On Wed, Jun 20, 2018 at 1:30 PM, Paul Shapley <p.shapley at gmail.com>
> wrote:
> >> >
> >> > Hi Users,
> >> >
> >> > Apologies if i'm posting this error again but i need to get pass the
> memory allocation issue of trying to allocate 3gb memory. The Grass version
> is (using file r.contour). Processor has 32 gb ram and i've allocated 30000
> mb under memory option of 'i.segment'.
> >> >
> >> > System Info
>
> >> > GRASS version: 7.4.1
>
> >> > GRASS SVN revision: r72807
>
> >> > Build date: 2018-06-13
>
> >> > Build platform: i386-w64-mingw32
>
> >> > GDAL: 2.2.4
>
> >> > PROJ.4: 4.9.3
>
> >> > GEOS: 3.5.0
>
> >> > SQLite: 3.17.0
>
> >> > Python: 2.7.4
>
> >> > wxPython: 2.8.12.1
>
> >> > Platform: Windows-2008ServerR2-6.1.7601-SP1 (OSGeo4W)
>
> >> >
>
> >> >
> >> > ERROR: G_malloc: unable to allocate 2995426350 bytes of memory at
> imagery/i.segment/flag.c:25
> >>
> >> this error appears because all other memory has already been allocated,
> there is less than 3 GB free RAM left.
> >>
> >> It seems that the current region has more than 20 billion grid cells.
> Does this match the input to i.segment? You might want to check the current
> region settings and compare them with extents and resolution as reported by
> r.info on the input to i.segment.
> >>
> >> Please provide the output of g.region -p and r.info if you want more
> detailed help.
> >>
> >> Markus M
> >>
> >> >
> >> > --
> >> > Paul J. Shapley MSc CGeog (GIS) FRGS
> >> >
> >> >
> >> > _______________________________________________
> >> > grass-user mailing list
> >> > grass-user at lists.osgeo.org
> >> > https://lists.osgeo.org/mailman/listinfo/grass-user
> >>
> >
> >
> >
> > --
> > Paul J. Shapley MSc CGeog (GIS) FRGS
> >
>



-- 
*Paul J. Shapley *MSc CGeog (GIS) FRGS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180621/5140a41d/attachment.html>