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
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
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
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
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
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
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
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.
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
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.
--
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
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
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
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
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
15 matches
Mail list logo
