[GRASS5] status of libgrass, mapserver, gdal and >8bit rasters
neteler at itc.it
Sun Mar 14 07:56:58 EST 2004
On Sat, Mar 13, 2004 at 02:32:54PM -0500, Frank Warmerdam wrote:
> Stephan Holl wrote:
> >Dear developers,
> >after some testing using the (quite outdated) libgrass-version with
> Then there is the more general question of whether I will be updating
> to catch up to more modern GRASS versions. I am not actually aware of any
> changes in GRASS raster support that would need an update of libgrass, but
> is my hope to modernize it at some point. Quite possibly in the near future
> everything provided by libgrass will be provided in the core GRASS shared
> libraries (libgis, etc) in a way suitable to replace the seperate libgrass.
a quick look into libgrass showed that a few (!) functions have
been added to libgrass with respect to the original libgis, libdatetime etc.
grep G_ gdal/frmts/grass/grassdataset.cpp | cut -d'G' -f2 | cut -d'(' -f1 |\
sed 's+^+G+g' |grep G_ | sort -u
x G_check_cell - opencell2.c
x G_get_cell_as_proj4 - get_proj4_def.c
x G_gisinit_2 - gisinit2.c
x: 3 new functions in libgrass
Maybe 2-4 underlying functions were also implemented.
Maybe move these few extra functions to
or 'libgis' and simply link GDAL against the shared libraries
of GRASS 5.3/5.7?
This would probably simplify everybodies life as
- you (someone else) don't have to maintain libgrass any more
- always latest libgis etc are used as taken from GRASS directly
- user need only GDAL and GRASS (the latter should be mostly
present as the user somehow has to create the GRASS DB when linking
MapServer to it)
I also think that we should release the GRASS libraries as stand-alone
package in future (probably with GRASS++ libs, let's jump into the license
discussion again...) to add more flexibility in GRASS packaging.
More information about the grass-dev