On 27 October 2016 at 13:53, Moritz Lennert <[email protected]> wrote:
> On 27/10/16 12:51, James Duffy wrote: > >> >> >> On 27 October 2016 at 11:45, Moritz Lennert >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> >> >> Le 27 octobre 2016 12:35:14 GMT+02:00, James Duffy >> <[email protected] <mailto:[email protected]>> >> a écrit : >> >On 27 October 2016 at 11:08, Moritz Lennert >> ><[email protected] <mailto:[email protected]>> >> >wrote: >> > >> >> >> >> >> >> Le 27 octobre 2016 11:22:02 GMT+02:00, James Duffy < >> >> [email protected] >> <mailto:[email protected]>> a écrit : >> >> >> >Hello, >> >> > >> >> >I'm trying to use i.segment.stats with GRASS 7.0.4 in the >> osgeolive >> >> >32bit >> >> >operating system. >> >> > >> >> >Prior to using this tool I have successfully created my segmented >> >map >> >> >using >> >> >i.segment. >> >> > >> >> >When I try to execute the following command: >> >> > >> >> >i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \ >> >> >rasters=gp_ortho.1@gp1,gp_ortho.2@gp1,gp_ortho.3@gp1,gp_ort >> ho.4@gp1 >> >\ >> >> >raster_statistics=min,max,mean,stddev,variance,sum \ >> >> >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \ >> >> >separator=comma >> >> > >> >> >I get this error: >> >> > >> >> >Calculating geometry statistics >> >> >ERROR: G_malloc: unable to allocate 4273800320 bytes of memory at >> >> > /tmp/tmpgzUtnA/r.object.geometry/main.c:129 >> >> >> >> This is coming from r.object.geometry. >> >> >> >> What are your region settings (g.region -p) ? How many segments do >> >you >> >> have ? >> >> >> > >> >GRASS 7.0.4 (GarronPill):~ > g.region -p >> >projection: 99 (OSGB 1936 / British National Grid) >> >zone: 0 >> >datum: osgb36 >> >ellipsoid: airy >> >north: 208007.00931776 >> >south: 207952.59780698 >> >west: 200993.90853302 >> >east: 201097.28911076 >> >nsres: 0.00430914 >> >ewres: 0.00430914 >> >rows: 12627 >> >cols: 23991 >> >cells: 302934357 >> >> Are you sure 4mm is correct for the resolution ? >> >> >> Yes. It's high resolution imagery from a drone. >> >> >> >> What does r.info <http://r.info> on >> >> >> > >> > >> >> >> >> Try running I.segment.stats without requesting form statistics. >> > >> > >> >Running: >> > >> >i.segment.stats --overwrite --verbose map=gp_seg_optimum@gp1 \ >> >csvfile=/home/jpd205/Wales_GRASS/GarronPill/gp_seg_stats \ >> >separator=comma >> >> Default is to do form statistics, so the above line also does. I >> have to admit that I don't know what happens when you give an empty >> parameter such as >> >> area_measures= or area_measures="" >> >> What does r.info <http://r.info> gp_seg_optimum give you ? >> >> >> >> +----------------------------------------------------------- >> -----------------+ >> | Map: gp_seg_optimum Date: Thu Oct 27 06:45:57 >> 2016 | >> | Mapset: gp1 Login of Creator: >> jpd205 | >> | Location: >> GarronPill | >> | DataBase: >> /home/jpd205/Wales_GRASS | >> | Title: ( gp_seg_optimum >> ) | >> | Timestamp: >> none | >> |---------------------------------------------------------- >> ------------------| >> | >> | >> | Type of Map: raster Number of Categories: >> 0 | >> | Data Type: >> CELL | >> | Rows: >> 12627 | >> | Columns: >> 23991 | >> | Total Cells: >> 302934357 | >> | Projection: OSGB 1936 / British National >> Grid | >> | N: 208007.00931776 S: 207952.59780698 Res: >> 0.00430914 | >> | E: 201097.28911076 W: 200993.90853302 Res: >> 0.00430914 | >> | Range of data: min = 35 max = >> 133556294 | >> | >> > > Ok, I think I see at least part of the problem: in GRASS 7.0 i.segment > numbers segments non sequentially, i.e. whenever a new segment is created > out of the merger of two existing segments, a new id is assigned. In GRASS > trunk (the development version) i.segment is rewritten to, at the end, > number all segments sequentially from 1 to the number of segments. > > r.object.geometry allocates memory according to the new system. As it says > in the code: > > /* REMARK: The following is only true if object ids are continuously > numbered */ > n_objects = max - min + 1; > obj_geos = G_malloc(n_objects * sizeof(struct obj_geo)); > > So, one solution would be to use the development version of GRASS. > Another would be to run r.clump on the result of the segmentation in order > to renumber the segments before running it through i.segment.stats. > This option seemed the most straightforward given my current setup. I ran r.clump with diagnoal enabled, and the output looked good. It only took 2mins to run. I then proceeded with the original i.segment.stats command and got the following: Calculating geometry statistics Calculating statistics for raster gp_ortho.1@gp1 ERROR: G_realloc: unable to allocate 572000 bytes of memory at raster/r.univar/r.univar_main.c:324 It looks like the tool got further, but is still getting stuck on something... > > A third option, potentially a bit faster than the second, would be to > write a little script which gets all category values from the segment map > (using r.category), and reassigns sequential category values to those using > r.reclass. I.e. something like this: > > r.category segment_map | awk 'BEGIN{cat=1} {printf"%d=%d\n", $1, cat; > cat++}' | r.reclass segment_map out=sequential_segment_map rules=- > > Moritz > > James
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
