g.region rast=mymap
r.mapcalc "mymap.copy = mymap"
Displaying both maps or r.univar gives vastly different results.
This corrupted output is not restricted to r.mapcalc but seems to be
true for all raster modules.
grass7 updated today, no changes in my local copy, two different
independent systems.
I know rasterlib in grass7 is work in progress, but I just wanted to
mention it, also ask if someone else observed this problem.
Markus M
On Wed, Jul 15, 2009 at 12:18 PM, Markus
Metz<markus.metz.giswork@googlemail.com> wrote:
g.region rast=mymap
r.mapcalc "mymap.copy = mymap"Displaying both maps or r.univar gives vastly different results.
This corrupted output is not restricted to r.mapcalc but seems to be
true for all raster modules.grass7 updated today, no changes in my local copy, two different
independent systems.I know rasterlib in grass7 is work in progress, but I just wanted to
mention it, also ask if someone else observed this problem.
I can confirm:
GRASS 7.0.svn (spearfish60):~/grass70 > g.region rast=elevation.dem
GRASS 7.0.svn (spearfish60):~/grass70 > r.mapcalc "new = elevation.dem"
100%
GRASS 7.0.svn (spearfish60):~/grass70 > r.univar -g elevation.dem
n=292317
null_cells=2661
min=1066
max=1840
range=774
mean=1353.66931789804
mean_of_abs=1353.66931789804
stddev=177.040679835105
variance=31343.402316476
coeff_var=13.0785766874004
sum=395700554
GRASS 7.0.svn (spearfish60):~/grass70 > r.univar -g new
n=292317
null_cells=2661
min=0
max=255
range=255
mean=133.548757000106
mean_of_abs=133.548757000106
stddev=67.9064484591162
variance=4611.28574233061
coeff_var=50.8476828871288
sum=39038572
No good.
GRASS 7.0.svn (spearfish60):~/grass70 > r.mapcalc "new_fp = elevation.10m"
100%
GRASS 7.0.svn (spearfish60):~/grass70 > r.univar -g elevation.10m
n=294978
null_cells=0
min=1061.116211
max=1845.375488
range=784.259277
mean=1348.37227305679
mean_of_abs=1348.37227305679
stddev=175.494048553447
variance=30798.1610776796
coeff_var=13.0152519493447
sum=397740156.3617459536
GRASS 7.0.svn (spearfish60):~/grass70 > r.univar -g new_fp
WARNING: Error reading map <new_fp@>, row 292
ERROR: Reading row 292
... even worse...
Markus
Hi,
2009/7/15 Markus Metz <markus.metz.giswork@googlemail.com>:
g.region rast=mymap
r.mapcalc "mymap.copy = mymap"Displaying both maps or r.univar gives vastly different results.
This corrupted output is not restricted to r.mapcalc but seems to be
true for all raster modules.grass7 updated today, no changes in my local copy, two different
independent systems.I know rasterlib in grass7 is work in progress, but I just wanted to
mention it, also ask if someone else observed this problem.
very wild guess - probably because Rast__init() is not called anywhere?
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Martin Landa wrote:
Hi,
2009/7/15 Markus Metz <markus.metz.giswork@googlemail.com>:
g.region rast=mymap
r.mapcalc "mymap.copy = mymap"Displaying both maps or r.univar gives vastly different results.
This corrupted output is not restricted to r.mapcalc but seems to be
true for all raster modules.grass7 updated today, no changes in my local copy, two different
independent systems.I know rasterlib in grass7 is work in progress, but I just wanted to
mention it, also ask if someone else observed this problem.
very wild guess - probably because Rast__init() is not called anywhere?
I guess you probably know best about Rast__init() and when and where it
is supposed to be called 
I've never heard of that function before...
Markus M
Hi,
2009/7/15 Markus Metz <markus.metz.giswork@googlemail.com>:
very wild guess - probably because Rast__init() is not called anywhere?
I guess you probably know best about Rast__init() and when and where it
is supposed to be called
well, I am really rasterlib newbie Hopefully fixed in r38425.
Anyway there are many modules which needs Rast_init() (or
Rast_init_all()).
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
On Wed, Jul 15, 2009 at 3:17 PM, Martin Landa<landa.martin@gmail.com> wrote:
Hi,
2009/7/15 Markus Metz <markus.metz.giswork@googlemail.com>:
very wild guess - probably because Rast__init() is not called anywhere?
I guess you probably know best about Rast__init() and when and where it
is supposed to be calledwell, I am really rasterlib newbie
It helps!
Anyway there are many modules which needs Rast_init() (or
Rast_init_all()).
Could it be done in the library to avoid the modification of all raster modules?
Markus
Hi,
2009/7/15 Markus Neteler <neteler@osgeo.org>:
[...]
Anyway there are many modules which needs Rast_init() (or
Rast_init_all()).Could it be done in the library to avoid the modification of all raster modules?
I am afraid that it's not possible (please correct me). The library
has been initialized by G_gisinit(). Currently G_gisinit() initializes
only gislib and rasterlib need to be initialized separately.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Martin Landa wrote:
Hi,
2009/7/15 Markus Neteler <neteler@osgeo.org>:
[...]
Anyway there are many modules which needs Rast_init() (or
Rast_init_all()).
Could it be done in the library to avoid the modification of all raster modules?
I am afraid that it's not possible (please correct me). The library
has been initialized by G_gisinit(). Currently G_gisinit() initializes
only gislib and rasterlib need to be initialized separately.
Sounds like in grass6, the rasterlib equivalent is initialized by
G_gisinit(). Is it really necessary to initialize rasterlib, no other
possibility? If yes, can't that be done by e.g. Rast_open_old/new?
Correct me if I'm wrong, but apart from gislib and rasterlib, no other
standard lib needs to be initialized? At least there is nothing like
Db_init() or Display_init() or Vect_init(). Modules currently rely on
G_gisinit() to provide all the stuff they need.
Markus M
Markus Metz wrote:
>>> Anyway there are many modules which needs Rast_init() (or
>>> Rast_init_all()).
>>>
>> Could it be done in the library to avoid the modification of all raster modules?
>>
>
> I am afraid that it's not possible (please correct me). The library
> has been initialized by G_gisinit(). Currently G_gisinit() initializes
> only gislib and rasterlib need to be initialized separately.
>
Sounds like in grass6, the rasterlib equivalent is initialized by
G_gisinit(). Is it really necessary to initialize rasterlib, no other
possibility? If yes, can't that be done by e.g. Rast_open_old/new?
Correct me if I'm wrong, but apart from gislib and rasterlib, no other
standard lib needs to be initialized? At least there is nothing like
Db_init() or Display_init() or Vect_init(). Modules currently rely on
G_gisinit() to provide all the stuff they need.
Splitting libgis into libgis and libraster means splitting G_gisinit()
into G_gisinit() and Rast_init(). Obviously, if you split the function
in two, any calls to the function also need to be split.
I'll look into doing one-shot initialisation within the raster
library.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Splitting libgis into libgis and libraster means splitting G_gisinit()
into G_gisinit() and Rast_init(). Obviously, if you split the function
in two, any calls to the function also need to be split.I'll look into doing one-shot initialisation within the raster
library.
It's a long stretch but what Rast_init() does may be in principle
similar to what does dig_init_portable() in the vector libs.
Initialisating of the raster libs in library instead of in module may
not be much of a time penalty since you're using static int initialized.
BTW, can a system with a byte order different from the byte order of the
original system read grass raster maps created on the original system?
Markus M
Markus Metz wrote:
> Splitting libgis into libgis and libraster means splitting G_gisinit()
> into G_gisinit() and Rast_init(). Obviously, if you split the function
> in two, any calls to the function also need to be split.
>
> I'll look into doing one-shot initialisation within the raster
> library.
>
It's a long stretch but what Rast_init() does may be in principle
similar to what does dig_init_portable() in the vector libs.
Initialisating of the raster libs in library instead of in module may
not be much of a time penalty since you're using static int initialized.BTW, can a system with a byte order different from the byte order of the
original system read grass raster maps created on the original system?
The core raster and vector file formats are portable. There are a few
instances where auxiliary files under cell_misc use platform-specific
formats, e.g. the FFT data generated by i.fft and read by i.fft (this
doesn't apply to 7.0, where the FFT data is stored as raster maps
rather than auxiliary files).
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
> >>> Anyway there are many modules which needs Rast_init() (or
> >>> Rast_init_all()).
> >>>
> >> Could it be done in the library to avoid the modification of all raster modules?
I'll look into doing one-shot initialisation within the raster
library.
Try r38429.
--
Glynn Clements <glynn@gclements.plus.com>
any opportunity here to kill off some more library-internal global variables?
Hamish
Glynn Clements wrote:
Markus Metz wrote:
Splitting libgis into libgis and libraster means splitting G_gisinit()
into G_gisinit() and Rast_init(). Obviously, if you split the function
in two, any calls to the function also need to be split.I'll look into doing one-shot initialisation within the raster
library.
It's a long stretch but what Rast_init() does may be in principle
similar to what does dig_init_portable() in the vector libs.
Initialisating of the raster libs in library instead of in module may
not be much of a time penalty since you're using static int initialized.BTW, can a system with a byte order different from the byte order of the
original system read grass raster maps created on the original system?
The core raster and vector file formats are portable. There are a few
instances where auxiliary files under cell_misc use platform-specific
formats, e.g. the FFT data generated by i.fft and read by i.fft (this
doesn't apply to 7.0, where the FFT data is stored as raster maps
rather than auxiliary files).
Thanks for the info. I admit I am too lazy to read the relevant code
(because I don't know where it is).
Getting more technical: does it make sense to port rasterIO ideas to
vectorIO or vice versa?
Markus M
On Wed, Jul 15, 2009 at 10:55 PM, Markus
Metz<markus.metz.giswork@googlemail.com> wrote:
...
Getting more technical: does it make sense to port rasterIO ideas to
vectorIO or vice versa?
(Un)related to this: I spoke to Gilberto Camara last week at the
OGRS2009 conference in Nantes (www.ogrs2009.org) about the
pros and cons of replacing the GRASS raster library with Terralib [1].
He promised to check with his engineers, maybe there is some
interesting advantage. To be studied...
Markus
Markus Neteler wrote:
I spoke to Gilberto Camara last week at the
OGRS2009 conference in Nantes (www.ogrs2009.org) about the
pros and cons of replacing the GRASS raster library with Terralib [1].
He promised to check with his engineers, maybe there is some
interesting advantage. To be studied...
IMHO, makes sense only if you get a dedicated grass developer adjusting
terralib to grass standards, otherwise it's only trouble. Plugging it in
as is will most probably not work.
Markus M
Markus Metz wrote:
Getting more technical: does it make sense to port rasterIO ideas to
vectorIO or vice versa?
I don't think so.
--
Glynn Clements <glynn@gclements.plus.com>
Hamish wrote:
any opportunity here to kill off some more library-internal global variables?
Not that I know of.
--
Glynn Clements <glynn@gclements.plus.com>