[GRASS-dev] GRASS7 rasterlib broken?
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
On Wed, Jul 15, 2009 at 12:18 PM, Markus Metzmarkus.metz.gisw...@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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
Hi, 2009/7/15 Markus Metz markus.metz.gisw...@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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
Martin Landa wrote: Hi, 2009/7/15 Markus Metz markus.metz.gisw...@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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
Hi, 2009/7/15 Markus Metz markus.metz.gisw...@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 ;-) I've never heard of that function before... 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
Hi, 2009/7/15 Markus Neteler nete...@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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
any opportunity here to kill off some more library-internal global variables? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 rasterlib broken?
Hamish wrote: any opportunity here to kill off some more library-internal global variables? Not that I know of. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
