Dear grass-dev's,
r.cross fails on G7 while it works fine in G6.
G7:
g.version -r
GRASS 7.0.svn (2013)
libgis Revision: 52468
G6:
.version -r
GRASS 6.4.3svn (2012)
Revision: 50937
My bad (, again)? Or is it really seg-faulting?
Best, Nikos
Nikos Alexandris wrote:
r.cross fails on G7 while it works fine in G6.
G7:
g.version -r
GRASS 7.0.svn (2013)
libgis Revision: 52468
I tested this in another machine -- the same G7 revision. r.cross justs
"waits...." -- no action at all.
G6:
.version -r
GRASS 6.4.3svn (2012)
Revision: 50937
In another machine -- same G6 revision. Works fine.
My bad (, again)? Or is it really seg-faulting?
Nikos
Nikos Alexandris wrote:
> r.cross fails on G7 while it works fine in G6.
> G7:
> g.version -r
> GRASS 7.0.svn (2013)
> libgis Revision: 52468I tested this in another machine -- the same G7 revision. r.cross justs
"waits...." -- no action at all.
FWIW, it works for me; sort of.
However: I note that it generates a distinct category for each cell
which is null in all inputs. If the number of cells is large and the
inputs contain many null cells, this could result in memory exhaustion
and/or extreme computation times.
I believe that the problem is due to an incomplete conversion from the
4.x G_get_map_row() function (which maps null to zero) to the 7.0
Rast_get_c_row() function (which leaves null as-is, i.e. -2^31). I.e.
it now reads nulls as nulls (instead of zeros) but doesn't actually
make any attempt to deal with the nulls which it gets.
--
Glynn Clements <glynn@gclements.plus.com>
Nikos Alexandris wrote:
> > r.cross fails on G7 while it works fine in G6.
> > G7:
> > g.version -r
> > GRASS 7.0.svn (2013)
> > libgis Revision: 52468
> I tested this in another machine -- the same G7 revision. r.cross justs
> "waits...." -- no action at all.
Glynn Clements wrote:
FWIW, it works for me; sort of.
However: I note that it generates a distinct category for each cell
which is null in all inputs. If the number of cells is large and the
inputs contain many null cells, this could result in memory exhaustion
and/or extreme computation times.I believe that the problem is due to an incomplete conversion from the
4.x G_get_map_row() function (which maps null to zero) to the 7.0
Rast_get_c_row() function (which leaves null as-is, i.e. -2^31). I.e.
it now reads nulls as nulls (instead of zeros) but doesn't actually
make any attempt to deal with the nulls which it gets.
Some attempts that _work_ on G7, are projected in
+proj=utm +no_defs +zone=34 +a=6378137 +rf=298.257223563
+towgs84=0.000,0.000,0.000 +to_meter=1
Crossing maps composed of
- 182402720 and 165183040 cells
or
- 165183040 and 165183040
Total cells in computational region are
- 458870596 (30m res)
- 165234916 (50m res)
But, r.cross might "result in memory exhaustion and/or extreme computation
times" in G7, in a Location defined by
+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 +y_0=3210000 +no_defs +a=6378137
+rf=298.257222101 +towgs84=0,0,0,0,0,0,0 +to_meter=1
Crossing maps composed of
- 263672500 and 263672500
Total cells in computational region are
65914160 (100m res)
Hope this info is of some use.
Best, Nikos
Glynn Clements wrote:
I believe that the problem is due to an incomplete conversion from the
4.x G_get_map_row() function (which maps null to zero) to the 7.0
Rast_get_c_row() function (which leaves null as-is, i.e. -2^31). I.e.
it now reads nulls as nulls (instead of zeros) but doesn't actually
make any attempt to deal with the nulls which it gets.
The issue should be fixed by r55276.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
> I believe that the problem is due to an incomplete conversion from the
> 4.x G_get_map_row() function (which maps null to zero) to the 7.0
> Rast_get_c_row() function (which leaves null as-is, i.e. -2^31). I.e.
> it now reads nulls as nulls (instead of zeros) but doesn't actually
> make any attempt to deal with the nulls which it gets.
The issue should be fixed by r55276.
Tested -- it gets going (at least in the previously mentioned failure with a
computational region of 65914160 cells).
Thank you Glynn 
Nikos
Nikos Alexandris wrote:
> > > r.cross fails on G7 while it works fine in G6.
> > > G7:
> > > g.version -r
> > > GRASS 7.0.svn (2013)
> > > libgis Revision: 52468
> > I tested this in another machine -- the same G7 revision. r.cross justs
> > "waits...." -- no action at all.
Glynn Clements wrote:
> FWIW, it works for me; sort of.
> However: I note that it generates a distinct category for each cell
> which is null in all inputs. If the number of cells is large and the
> inputs contain many null cells, this could result in memory exhaustion
> and/or extreme computation times.
> I believe that the problem is due to an incomplete conversion from the
> 4.x G_get_map_row() function (which maps null to zero) to the 7.0
> Rast_get_c_row() function (which leaves null as-is, i.e. -2^31). I.e.
> it now reads nulls as nulls (instead of zeros) but doesn't actually
> make any attempt to deal with the nulls which it gets.
[..]
...r.cross might "result in memory exhaustion and/or extreme computation
times" in G7, in a Location defined by
+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 +y_0=3210000 +no_defs +a=6378137
+rf=298.257222101 +towgs84=0,0,0,0,0,0,0 +to_meter=1
Crossing maps composed of
- 263672500 and 263672500Total cells in computational region are
65914160 (100m res)
Oh... now I see it: more important I guess is the number of NULL cells of the
maps to be crossed! FWIW, they were/are (in the failing case):
61149574 and 63837480
Thanks again, Nikos