<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 27 October 2016 at 16:33, Moritz Lennert <span dir="ltr"><<a target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail-HOEnZb"><div class="gmail-h5">On 27/10/16 16:15, Moritz Lennert wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
On 27/10/16 15:38, James Duffy wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<br>
<br>
On 27 October 2016 at 13:53, Moritz Lennert<br>
<<a target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a> <mailto:<a target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonl<wbr>ine.be</a>>><br>
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 target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a><br>
<mailto:<a target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonl<wbr>ine.be</a>><br>
<mailto:<a target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonl<wbr>ine.be</a><br>
<mailto:<a target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonl<wbr>ine.be</a>>>> wrote:<br>
<br>
<br>
<br>
Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy<br>
<<a target="_blank" href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gmail.com</a><br>
<mailto:<a target="_blank" href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gma<wbr>il.com</a>><br>
<mailto:<a target="_blank" href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gma<wbr>il.com</a><br>
<mailto:<a target="_blank" href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gma<wbr>il.com</a>>>><br>
a écrit :<br>
>On 27 October 2016 at 11:08, Moritz Lennert<br>
><<a target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a><br>
<mailto:<a target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonl<wbr>ine.be</a>><br>
<mailto:<a target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonl<wbr>ine.be</a><br>
<mailto:<a target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonl<wbr>ine.be</a>>>><br>
>wrote:<br>
><br>
>><br>
>><br>
>> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy <<br>
>> <a target="_blank" href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gmail.com</a><br>
<mailto:<a target="_blank" href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gma<wbr>il.com</a>><br>
<mailto:<a target="_blank" href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gma<wbr>il.com</a><br>
<mailto:<a target="_blank" href="mailto:james.philip.duffy@gmail.com">james.philip.duffy@gma<wbr>il.com</a>>>> a écrit :<br>
<br>
>> >Hello,<br>
>> ><br>
>> >I'm trying to use i.segment.stats with GRASS 7.0.4 in<br>
the osgeolive<br>
>> >32bit<br>
>> >operating system.<br>
>> ><br>
>> >Prior to using this tool I have successfully 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_ort<wbr>ho.2@gp1,gp_ortho.3@gp1,gp_ort<wbr>ho.4@gp1<br>
>\<br>
>> >raster_statistics=min,max,mea<wbr>n,stddev,variance,sum \<br>
>><br>
>csvfile=/home/jpd205/Wales_GR<wbr>ASS/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 bytes of<br>
memory at<br>
>> > /tmp/tmpgzUtnA/r.object.geome<wbr>try/main.c:129<br>
>><br>
>> This is coming from r.object.geometry.<br>
>><br>
>> What are your region settings (g.region -p) ? How 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 target="_blank" rel="noreferrer" href="http://r.info">r.info</a> <<a target="_blank" rel="noreferrer" href="http://r.info">http://r.info</a>> <<a target="_blank" rel="noreferrer" href="http://r.info">http://r.info</a>> on<br>
<br>
<br>
><br>
><br>
>><br>
>> Try running I.segment.stats without requesting 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_GR<wbr>ASS/GarronPill/gp_seg_stats \<br>
>separator=comma<br>
<br>
Default is to do form statistics, so the above line also<br>
does. I<br>
have to admit that I don't know what happens when you give<br>
an empty<br>
parameter such as<br>
<br>
area_measures= or area_measures=""<br>
<br>
What does <a target="_blank" rel="noreferrer" href="http://r.info">r.info</a> <<a target="_blank" rel="noreferrer" href="http://r.info">http://r.info</a>> <<a target="_blank" rel="noreferrer" href="http://r.info">http://r.info</a>><br>
gp_seg_optimum give you ?<br>
<br>
<br>
<br>
<br>
+-----------------------------<wbr>------------------------------<wbr>-----------------+<br>
<br>
| Map: gp_seg_optimum Date: Thu Oct 27<br>
06:45:57<br>
2016 |<br>
| Mapset: gp1 Login of Creator:<br>
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>
|-----------------------------<wbr>------------------------------<wbr>-----------------|<br>
<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 = 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 new<br>
segment is created out of the merger of two existing segments, a new<br>
id is assigned. In GRASS trunk (the development version) i.segment<br>
is rewritten to, at the end, number all segments sequentially from 1<br>
to the number of segments.<br>
<br>
r.object.geometry allocates memory according to the new system. As<br>
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 GRASS.<br>
<br>
<br>
<br>
Another would be to run r.clump on the result of the segmentation in<br>
order to renumber the segments before running it through<br>
i.segment.stats.<br>
<br>
<br>
This option seemed the most straightforward given my current setup. I<br>
ran r.clump with diagnoal enabled, and the output looked good. It only<br>
took 2mins to run.<br>
<br>
I then proceeded with the original i.segment.stats command and got the<br>
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_<wbr>main.c:324<br>
<br>
It looks like the tool got further, but is still getting stuck on<br>
something...<br>
</blockquote>
<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>
</blockquote>
<br></div></div>
Could you run<br>
<br>
r.univar -et gp_ortho.1 zones=ClumpedSegmentMap output=testoutput.csv<br>
<br>
to if r.univar by itself handles this (which would mean I could try to change the data handling in i.segment.stats to make it more memory efficient), or not ?<br>
<br>
Thanks !<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
Moritz<br>
</font></span></blockquote></div><br></div><div class="gmail_extra"><a href="http://r.info">r.info</a> on the clumped map gives:<br><br> +----------------------------------------------------------------------------+<br> | Map: gp_seg_optimum_clump Date: Thu Oct 27 14:28:30 2016 |<br> | Mapset: gp1 Login of Creator: jpd205 |<br> | Location: GarronPill |<br> | DataBase: /home/jpd205/Wales_GRASS |<br> | Title: gp_seg_optimum_clump ( gp_seg_optimum_clump ) |<br> | Timestamp: none |<br> |----------------------------------------------------------------------------|<br> | |<br> | Type of Map: raster Number of Categories: 0 |<br> | Data Type: CELL |<br> | Rows: 12627 |<br> | Columns: 23991 |<br> | Total Cells: 302934357 |<br> | Projection: OSGB 1936 / British National Grid |<br> | N: 208007.00931776 S: 207952.59780698 Res: 0.00430914 |<br> | E: 201097.28911076 W: 200993.90853302 Res: 0.00430914 |<br> | Range of data: min = 1 max = 1264957 |<br> | |<br> | Data Source: |<br> | gp_seg_optimum@gp1 |<br> | |<br> | |<br> | Data Description: |<br> | generated by r.clump |<br> | |<br> | Comments: |<br> | r.clump --overwrite --verbose -d input="gp_seg_optimum@gp1" output="\ |<br> | gp_seg_optimum_clump" title="gp_seg_optimum_clump" |<br> | |<br> +----------------------------------------------------------------------------+<br><br></div><div class="gmail_extra">Running:<br></div><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra">r.univar -et gp_ortho.1 zones=gp_seg_optimum_clump output=testoutput2.csv <br><br></div><div class="gmail_extra">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.c:324<br><br></div><div class="gmail_extra">James<br></div><div class="gmail_extra"><br><br></div></div>