Hi,
I started a wiki page dedicated to the raster lib in GRASS7. The page
currently contains initial list of functions which should be moved
from libGIS.
http://trac.osgeo.org/grass/wiki/Grass7RasterLib
Logically raster lib should be placed in 'lib/raster'. Currently there
are R_() functions. Where should be moved content of 'lib/raster'?
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Hi,
2009/6/18 Martin Landa <landa.martin@gmail.com>:
I renamed this page to
http://trac.osgeo.org/grass/wiki/Grass7/RasterLib
Trac wiki has no 'move' button, so previous link doesn't work. Sorry for that.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Martin Landa wrote:
I started a wiki page dedicated to the raster lib in GRASS7. The page
currently contains initial list of functions which should be moved
from libGIS.http://trac.osgeo.org/grass/wiki/Grass7RasterLib
Logically raster lib should be placed in 'lib/raster'. Currently there
are R_() functions. Where should be moved content of 'lib/raster'?
I suppose that it can be merged into lib/display, as that's mostly
what uses it.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/6/19 Glynn Clements <glynn@gclements.plus.com>:
I started a wiki page dedicated to the raster lib in GRASS7. The page
currently contains initial list of functions which should be moved
from libGIS.http://trac.osgeo.org/grass/wiki/Grass7RasterLib
Logically raster lib should be placed in 'lib/raster'. Currently there
are R_() functions. Where should be moved content of 'lib/raster'?I suppose that it can be merged into lib/display, as that's mostly
what uses it.
I don't know display library so well, but I would guess that the
merging cannot be done automatically (just rename R_ to D_). I have
created for this purpose wiki page, feel free to updated it
http://trac.osgeo.org/grass/wiki/Grass7/DisplayLib
Thanks, Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Martin Landa wrote:
>> I started a wiki page dedicated to the raster lib in GRASS7. The page
>> currently contains initial list of functions which should be moved
>> from libGIS.
>>
>> http://trac.osgeo.org/grass/wiki/Grass7RasterLib
>>
>> Logically raster lib should be placed in 'lib/raster'. Currently there
>> are R_() functions. Where should be moved content of 'lib/raster'?
>
> I suppose that it can be merged into lib/display, as that's mostly
> what uses it.I don't know display library so well, but I would guess that the
merging cannot be done automatically (just rename R_ to D_). I have
created for this purpose wiki page, feel free to updated it
I don't suggest renaming the functions, just moving raster.c to
lib/display.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/6/19 Glynn Clements <glynn@gclements.plus.com>:
>> I started a wiki page dedicated to the raster lib in GRASS7. The page
>> currently contains initial list of functions which should be moved
>> from libGIS.
>>
>> http://trac.osgeo.org/grass/wiki/Grass7RasterLib
>>
>> Logically raster lib should be placed in 'lib/raster'. Currently there
>> are R_() functions. Where should be moved content of 'lib/raster'?
>
> I suppose that it can be merged into lib/display, as that's mostly
> what uses it.I don't know display library so well, but I would guess that the
merging cannot be done automatically (just rename R_ to D_). I have
created for this purpose wiki page, feel free to updated itI don't suggest renaming the functions, just moving raster.c to
lib/display.
OK, but shouldn't be better to use the same prefix for all fns from
the display library?
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Martin Landa wrote:
>> >> I started a wiki page dedicated to the raster lib in GRASS7. The page
>> >> currently contains initial list of functions which should be moved
>> >> from libGIS.
>> >>
>> >> http://trac.osgeo.org/grass/wiki/Grass7RasterLib
>> >>
>> >> Logically raster lib should be placed in 'lib/raster'. Currently there
>> >> are R_() functions. Where should be moved content of 'lib/raster'?
>> >
>> > I suppose that it can be merged into lib/display, as that's mostly
>> > what uses it.
>>
>> I don't know display library so well, but I would guess that the
>> merging cannot be done automatically (just rename R_ to D_). I have
>> created for this purpose wiki page, feel free to updated it
>
> I don't suggest renaming the functions, just moving raster.c to
> lib/display.OK, but shouldn't be better to use the same prefix for all fns from
the display library?
Many of the R_* functions have matching D_* functions with the same
name (modulo the prefix) and "matching" functionality.
OTOH, many of the R_* functions no longer need to be externally
visible. AFAICT, only the following are used other than by
lib/display:
R_close_driver
R_encoding
R_erase
R_font
R_font_info
R_font_list
R_get_window
R_open_driver
R_text
R_text_rotation
R_text_size
Everything else can be made "static" (or eliminated; most of them are
just aliases for the corresponding COM_* functions in lib/driver).
AFAICT, all of the above except for R_erase() can be changed to D_*;
none of the other R_* functions which have matching D_* versions are
used externally.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/6/20 Glynn Clements <glynn@gclements.plus.com>:
[...]
OTOH, many of the R_* functions no longer need to be externally
visible. AFAICT, only the following are used other than by
lib/display:R_close_driver
R_encoding
R_erase
R_font
R_font_info
R_font_list
R_get_window
R_open_driver
R_text
R_text_rotation
R_text_sizeEverything else can be made "static" (or eliminated; most of them are
just aliases for the corresponding COM_* functions in lib/driver).AFAICT, all of the above except for R_erase() can be changed to D_*;
none of the other R_* functions which have matching D_* versions are
used externally.
OK, partly done r38001.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Hi,
2009/6/19 Martin Landa <landa.martin@gmail.com>:
I have moved selected fns from gislib to the new rasterlib. The list
is very initial (some fns should be renamed, removed, etc.), I fixed
also the modules to be compiled. The GIS and Raster library need to be
clean up. The current stage is very initial.
I am not sure if G__ structure from G.h should be completely
initialized by GIS or Raster library or the structures from G.h should
be split and initialized separately by both libraries?
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Martin Landa wrote:
I am not sure if G__ structure from G.h should be completely
initialized by GIS or Raster library or the structures from G.h should
be split and initialized separately by both libraries?
AFAICT, there are two options:
1. The current region belongs to libraster; in which case, G__ belongs
in libraster, along with anything which uses it.
2. The current region belongs to libgis; in which case, G__ needs to
have the window and window_set fields moved back to libgis, and
everything which uses the remaining fields needs to be moved to
libraster.
As it stands, G.h has been moved to lib/raster, yet G__ is still
defined by libgis.Nothing in libgis should be including
"../raster/G.h". This needs to be fixed as a priority (personally, I
wouldn't have started committing anything until this was sorted out).
BTW, I intend to rename Rast.h to raster.h, to match (almost)
everything else in GRASS. Vect.h was a mistake, which I see no reason
to repeat.
--
Glynn Clements <glynn@gclements.plus.com>
Martin Landa wrote:
I have moved selected fns from gislib to the new rasterlib. The list
is very initial (some fns should be renamed, removed, etc.), I fixed
also the modules to be compiled. The GIS and Raster library need to be
clean up. The current stage is very initial.I am not sure if G__ structure from G.h should be completely
initialized by GIS or Raster library or the structures from G.h should
be split and initialized separately by both libraries?
As you've noticed, the latter was done.
However, the global change of G_set_window() to Rast_set_window() in
r38009 is wrong.
Rast_set_window() updates the raster window and the column mapping for
open rasters. It doesn't affect G__.window, which is used by
G_window_{rows,cols}() etc.
Some of the code which used G_set_window() will need to continue using
G_set_window(), some of it will need to use Rast_set_window(), and
some of it will need to call both.
Right now, I suspect that many (or even most) modules which used
G_set_window() are broken.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/6/24 Glynn Clements <glynn@gclements.plus.com>:
I have moved selected fns from gislib to the new rasterlib. The list
is very initial (some fns should be renamed, removed, etc.), I fixed
also the modules to be compiled. The GIS and Raster library need to be
clean up. The current stage is very initial.I am not sure if G__ structure from G.h should be completely
initialized by GIS or Raster library or the structures from G.h should
be split and initialized separately by both libraries?As you've noticed, the latter was done.
thanks for cleaning it up.
[...]
I have prepared list of fns, see [1]. I would suggest to rename some
of them. Waiting for you comments.
Martin
[1] http://trac.osgeo.org/grass/wiki/Grass7/RasterLib
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Martin Landa wrote:
>> I have moved selected fns from gislib to the new rasterlib. The list
>> is very initial (some fns should be renamed, removed, etc.), I fixed
>> also the modules to be compiled. The GIS and Raster library need to be
>> clean up. The current stage is very initial.
>>
>> I am not sure if G__ structure from G.h should be completely
>> initialized by GIS or Raster library or the structures from G.h should
>> be split and initialized separately by both libraries?
>
> As you've noticed, the latter was done.thanks for cleaning it up.
[...]
I have prepared list of fns, see [1]. I would suggest to rename some
of them. Waiting for you comments.
color_str.c should remain in libgis; it isn't specific to rasters
(e.g. it's also used by display modules).
G_incr_void_ptr() should probably be kept in libgis.
I'm not entirely sure about interp.c. There might be non-raster uses
for it, although DCELL should be changed to double if it's kept in
libgis.
But the window issue should be the priority right now.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/6/25 Glynn Clements <glynn@gclements.plus.com>:
[...]
I have prepared list of fns, see [1]. I would suggest to rename some
of them. Waiting for you comments.color_str.c should remain in libgis; it isn't specific to rasters
(e.g. it's also used by display modules).
OK, done in r38069.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Hi,
2009/6/25 Glynn Clements <glynn@gclements.plus.com>:
[...]
G_incr_void_ptr() should probably be kept in libgis.
done in r38073.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa