<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 27 October 2016 at 17:48, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le Thu, 27 Oct 2016 16:45:47 +0100,<br>
James Duffy <<a href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gmail.com</a>> a écrit :<br>
<div><div class="h5"><br>
> On 27 October 2016 at 16:33, Moritz Lennert<br>
> <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>
><br>
> > On 27/10/16 16:15, Moritz Lennert wrote:<br>
> ><br>
> >> On 27/10/16 15:38, James Duffy wrote:<br>
> >><br>
> >>><br>
> >>><br>
> >>> On 27 October 2016 at 13:53, Moritz Lennert<br>
> >>> <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a><br>
> >>> <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.<wbr>worldonline.be</a>>> wrote:<br>
> >>><br>
> >>>     On 27/10/16 12:51, James Duffy wrote:<br>
> >>><br>
> >>><br>
> >>><br>
> >>>         On 27 October 2016 at 11:45, Moritz Lennert<br>
> >>>         <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a><br>
> >>>         <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.<wbr>worldonline.be</a>><br>
> >>>         <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.<wbr>worldonline.be</a><br>
> >>>         <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.<wbr>worldonline.be</a>>>> wrote:<br>
> >>><br>
> >>><br>
> >>><br>
> >>>             Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy<br>
> >>>             <<a href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gmail.com</a><br>
> >>>         <mailto:<a href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@<wbr>gmail.com</a>><br>
> >>>         <mailto:<a href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@<wbr>gmail.com</a><br>
> >>>         <mailto:<a href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@<wbr>gmail.com</a>>>><br>
> >>>             a écrit :<br>
> >>>             >On 27 October 2016 at 11:08, Moritz Lennert<br>
> >>>             ><<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a><br>
> >>>         <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.<wbr>worldonline.be</a>><br>
> >>>         <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.<wbr>worldonline.be</a><br>
> >>>         <mailto:<a href="mailto:mlennert@club.worldonline.be">mlennert@club.<wbr>worldonline.be</a>>>><br>
> >>>             >wrote:<br>
> >>>             ><br>
> >>>             >><br>
> >>>             >><br>
> >>>             >> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy<br>
> >>>             >> < <a href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gmail.com</a><br>
> >>>         <mailto:<a href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@<wbr>gmail.com</a>><br>
> >>>             <mailto:<a href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@<wbr>gmail.com</a><br>
> >>>         <mailto:<a href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@<wbr>gmail.com</a>>>> a écrit :<br>
> >>><br>
> >>>             >> >Hello,<br>
> >>>             >> ><br>
> >>>             >> >I'm trying to use i.segment.stats with GRASS<br>
> >>>             >> >7.0.4 in<br>
> >>>         the osgeolive<br>
> >>>             >> >32bit<br>
> >>>             >> >operating system.<br>
> >>>             >> ><br>
> >>>             >> >Prior to using this tool I have successfully<br>
> >>>             >> >created my<br>
> >>>         segmented<br>
> >>>             >map<br>
> >>>             >> >using<br>
> >>>             >> >i.segment.<br>
> >>>             >> ><br>
> >>>             >> >When I try to execute the following command:<br>
> >>>             >> ><br>
> >>>             >> >i.segment.stats --overwrite --verbose<br>
> >>>         map=gp_seg_optimum@gp1 \<br>
> >>>             >><br>
> >>><br>
> >>> >rasters=gp_ortho.1@gp1,gp_<wbr>ortho.2@gp1,gp_ortho.3@gp1,gp_<wbr>ortho.4@gp1<br>
> >>>             >\<br>
> >>>             >> >raster_statistics=min,max,<wbr>mean,stddev,variance,sum<br>
> >>>             >> >\<br>
> >>>             >><br>
> >>> >csvfile=/home/jpd205/Wales_<wbr>GRASS/GarronPill/gp_seg_stats \<br>
> >>>             >> >separator=comma<br>
> >>>             >> ><br>
> >>>             >> >I get this error:<br>
> >>>             >> ><br>
> >>>             >> >Calculating geometry statistics<br>
> >>>             >> >ERROR: G_malloc: unable to allocate 4273800320<br>
> >>>             >> >bytes of<br>
> >>>         memory at<br>
> >>>             >> >       /tmp/tmpgzUtnA/r.object.<wbr>geometry/main.c:129<br>
> >>>             >><br>
> >>>             >> This is coming from r.object.geometry.<br>
> >>>             >><br>
> >>>             >> What are your region settings (g.region -p) ? How<br>
> >>>             >> many<br>
> >>>         segments do<br>
> >>>             >you<br>
> >>>             >> have ?<br>
> >>>             >><br>
> >>>             ><br>
> >>>             >GRASS 7.0.4 (GarronPill):~ > g.region -p<br>
> >>>             >projection: 99 (OSGB 1936 / British National Grid)<br>
> >>>             >zone:       0<br>
> >>>             >datum:      osgb36<br>
> >>>             >ellipsoid:  airy<br>
> >>>             >north:      208007.00931776<br>
> >>>             >south:      207952.59780698<br>
> >>>             >west:       200993.90853302<br>
> >>>             >east:       201097.28911076<br>
> >>>             >nsres:      0.00430914<br>
> >>>             >ewres:      0.00430914<br>
> >>>             >rows:       12627<br>
> >>>             >cols:       23991<br>
> >>>             >cells:      302934357<br>
> >>><br>
> >>>             Are you sure 4mm is correct for the resolution ?<br>
> >>><br>
> >>><br>
> >>>         Yes. It's high resolution imagery from a drone.<br>
> >>><br>
> >>><br>
> >>><br>
> >>>             What does <a href="http://r.info" rel="noreferrer" target="_blank">r.info</a> <<a href="http://r.info" rel="noreferrer" target="_blank">http://r.info</a>> <<a href="http://r.info" rel="noreferrer" target="_blank">http://r.info</a>> on<br>
> >>><br>
> >>><br>
> >>>             ><br>
> >>>             ><br>
> >>>             >><br>
> >>>             >> Try running I.segment.stats without requesting<br>
> >>>             >> form<br>
> >>>         statistics.<br>
> >>>             ><br>
> >>>             ><br>
> >>>             >Running:<br>
> >>>             ><br>
> >>>             >i.segment.stats --overwrite --verbose<br>
> >>> map=gp_seg_optimum@gp1 \<br>
> >>>             >csvfile=/home/jpd205/Wales_<wbr>GRASS/GarronPill/gp_seg_stats<br>
> >>>             >\ separator=comma<br>
> >>><br>
> >>>             Default is to do form statistics, so the above line<br>
> >>> also does. I<br>
> >>>             have to admit that I don't know what happens when you<br>
> >>> give an empty<br>
> >>>             parameter such as<br>
> >>><br>
> >>>             area_measures= or area_measures=""<br>
> >>><br>
> >>>             What does <a href="http://r.info" rel="noreferrer" target="_blank">r.info</a> <<a href="http://r.info" rel="noreferrer" target="_blank">http://r.info</a>> <<a href="http://r.info" rel="noreferrer" target="_blank">http://r.info</a>><br>
> >>>         gp_seg_optimum give you ?<br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> +-----------------------------<wbr>------------------------------<br>
> >>> -----------------+<br>
> >>><br>
> >>>          | Map:      gp_seg_optimum                 Date: Thu Oct<br>
> >>> 27 06:45:57<br>
> >>>         2016    |<br>
> >>>          | Mapset:   gp1                            Login of<br>
> >>> Creator: jpd205          |<br>
> >>>          | Location:<br>
> >>><br>
> >>> GarronPill                                                       |<br>
> >>>          | DataBase:<br>
> >>><br>
> >>> /home/jpd205/Wales_GRASS                                         |<br>
> >>>          | Title:     ( gp_seg_optimum<br>
> >>>         )                                              |<br>
> >>>          | Timestamp:<br>
> >>>         none<br>
> >>> |<br>
> >>><br>
> >>> |-----------------------------<wbr>------------------------------<br>
> >>> -----------------|<br>
> >>><br>
> >>>          |<br>
> >>>         |<br>
> >>>          |   Type of Map:  raster               Number of<br>
> >>> Categories: 0               |<br>
> >>>          |   Data Type:<br>
> >>>         CELL<br>
> >>> | |   Rows:<br>
> >>>         12627<br>
> >>> | |   Columns:<br>
> >>>         23991<br>
> >>> | |   Total Cells:<br>
> >>>         302934357<br>
> >>> | |        Projection: OSGB 1936 / British National<br>
> >>>         Grid                       |<br>
> >>>          |            N: 208007.00931776    S: 207952.59780698<br>
> >>> Res: 0.00430914      |<br>
> >>>          |            E: 201097.28911076    W: 200993.90853302<br>
> >>> Res: 0.00430914      |<br>
> >>>          |   Range of data:    min = 35  max =<br>
> >>>         133556294                              |<br>
> >>>          |<br>
> >>><br>
> >>><br>
> >>>     Ok, I think I see at least part of the problem: in GRASS 7.0<br>
> >>>     i.segment numbers segments non sequentially, i.e. whenever a<br>
> >>> new segment is created out of the merger of two existing<br>
> >>> segments, a new id is assigned. In GRASS trunk (the development<br>
> >>> version) i.segment is rewritten to, at the end, number all<br>
> >>> segments sequentially from 1 to the number of segments.<br>
> >>><br>
> >>>     r.object.geometry allocates memory according to the new<br>
> >>> system. As it says in the code:<br>
> >>><br>
> >>>         /* REMARK: The following is only true if object ids are<br>
> >>>     continuously numbered */<br>
> >>>         n_objects = max - min + 1;<br>
> >>>         obj_geos = G_malloc(n_objects * sizeof(struct obj_geo));<br>
> >>><br>
> >>>     So, one solution would be to use the development version of<br>
> >>> GRASS.<br>
> >>><br>
> >>><br>
> >>><br>
> >>>     Another would be to run r.clump on the result of the<br>
> >>> segmentation in order to renumber the segments before running it<br>
> >>> through i.segment.stats.<br>
> >>><br>
> >>><br>
> >>> This option seemed the most straightforward given my current<br>
> >>> setup. I ran r.clump with diagnoal enabled, and the output looked<br>
> >>> good. It only took 2mins to run.<br>
> >>><br>
> >>> I then proceeded with the original i.segment.stats command and<br>
> >>> got the following:<br>
> >>><br>
> >>> Calculating geometry statistics<br>
> >>> Calculating statistics for raster gp_ortho.1@gp1<br>
> >>> ERROR: G_realloc: unable to allocate 572000 bytes of memory at<br>
> >>>        raster/r.univar/r.univar_main.<wbr>c:324<br>
> >>><br>
> >>> It looks like the tool got further, but is still getting stuck on<br>
> >>> something...<br>
> >>><br>
> >><br>
> >> Yes, now there a memory issue in the part where it uses r.univar to<br>
> >> calculate statistics per segment on one of the spectral bands.<br>
> >><br>
> ><br>
> > Could you run<br>
> ><br>
> > r.univar -et gp_ortho.1 zones=ClumpedSegmentMap<br>
> > output=testoutput.csv<br>
> ><br>
> > to if r.univar by itself handles this (which would mean I could try<br>
> > to change the data handling in i.segment.stats to make it more<br>
> > memory efficient), or not ?<br>
> ><br>
> > Thanks !<br>
> ><br>
> > Moritz<br>
> ><br>
><br>
> <a href="http://r.info" rel="noreferrer" target="_blank">r.info</a> on the clumped map gives:<br>
><br>
>  +-----------------------------<wbr>------------------------------<wbr>-----------------+<br>
>  | Map:      gp_seg_optimum_clump           Date: Thu Oct 27 14:28:30<br>
> 2016    |<br>
>  | Mapset:   gp1                            Login of Creator:<br>
> jpd205          |<br>
>  | Location:<br>
> GarronPill                                                       |<br>
>  | DataBase:<br>
> /home/jpd205/Wales_GRASS                                         |<br>
>  | Title:    gp_seg_optimum_clump ( gp_seg_optimum_clump<br>
> )                    |<br>
>  | Timestamp:<br>
> none                                                            |<br>
>  |-----------------------------<wbr>------------------------------<wbr>-----------------|<br>
>  |<br>
> |<br>
>  |   Type of Map:  raster               Number of Categories:<br>
> 0               |<br>
>  |   Data Type:<br>
> CELL                                                       |<br>
>  |   Rows:<br>
> 12627                                                      |<br>
>  |   Columns:<br>
> 23991                                                      |<br>
>  |   Total Cells:<br>
> 302934357                                                  |<br>
>  |        Projection: OSGB 1936 / British National<br>
> Grid                       |<br>
>  |            N: 208007.00931776    S: 207952.59780698   Res:<br>
> 0.00430914      |<br>
>  |            E: 201097.28911076    W: 200993.90853302   Res:<br>
> 0.00430914      |<br>
>  |   Range of data:    min = 1  max =<br>
> 1264957                                 |<br>
>  |<br>
> |<br>
>  |   Data<br>
> Source:                                                             |<br>
>  |    gp_seg_optimum@gp1<br>
> |<br>
>  |<br>
> |<br>
>  |<br>
> |<br>
>  |   Data<br>
> Description:                                                        |<br>
>  |    generated by<br>
> r.clump                                                    |<br>
>  |<br>
> |<br>
>  |<br>
> Comments:<br>
> | |    r.clump --overwrite --verbose -d input="gp_seg_optimum@gp1"<br>
> output="\   |<br>
>  |    gp_seg_optimum_clump"<br>
> title="gp_seg_optimum_clump"                      |<br>
>  |<br>
> |<br>
>  +-----------------------------<wbr>------------------------------<wbr>-----------------+<br>
><br>
> Running:<br>
><br>
> r.univar -et gp_ortho.1 zones=gp_seg_optimum_clump<br>
> output=testoutput2.csv<br>
><br>
> Returns:<br>
><br>
> Current region rows: 12627, cols: 23991<br>
> ERROR: G_realloc: unable to allocate 224000 bytes of memory at<br>
>        raster/r.univar/r.univar_main.<wbr>c:324<br>
<br>
<br>
</div></div>Ok, so the issue is with r.univar (although the issue has made me<br>
aware that i.segment.stats could be made way more memory efficient<br>
as well).<br>
<br>
How much RAM do you have on your machine ?<br></blockquote><div><br></div><div>It's a virtual machine which I have dedicated about 10GB. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This warrants a bug report. Would you be willing to file one on<br>
<a href="http://trac.osgeo.org/grass" rel="noreferrer" target="_blank">http://trac.osgeo.org/grass</a> ?<br></blockquote><div><br></div><div>I'm happy to submit it if you can guide me as to what exactly should go into it please? <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Moritz<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">James<br clear="all"></div><div class="gmail_extra"><br></div></div>