Dear developers,
after some testing using the (quite outdated) libgrass-version with
gdal, grass and mapserver I would like to know, if there are some
initiatives to make libgrass/gdal support more than 256 colors. I am no
programmer but I like to know if this would be a big deal to implement
(because I am strongly interested in using it).
It would be a real benefit for the interaction with mapserver, if
raster-support directly from a a GRASS-Location could be possible, I
think.
Perhaps anybody from the core-developers could give some comments on
this topic.
Thanks in advance.
Stephan Holl
--
Stephan Holl
Check headers for GnuPG Key!
17:06:15 up 6:34, 1 user, load average: 0.11, 0.09, 0.02
Stephan Holl wrote:
Dear developers,
after some testing using the (quite outdated) libgrass-version with
gdal, grass and mapserver I would like to know, if there are some
initiatives to make libgrass/gdal support more than 256 colors. I am no
programmer but I like to know if this would be a big deal to implement
(because I am strongly interested in using it).
It would be a real benefit for the interaction with mapserver, if
raster-support directly from a a GRASS-Location could be possible, I
think.
Perhaps anybody from the core-developers could give some comments on
this topic.
Stephan,
It what sense would you like to support >8bit rasters? The GDAL access to
GRASS rasters via libgrass already supports floating point rasters, and
integer rasters with >8 bit pixel data types. There may (or may not, I'm
not too sure) be a limit only 256 colors in the driver though that isn't
a requirements of GDAL.
Is the issue at the MapServer end? MapServer has supported >8bit rasters
for a while, but by scaling them to 8bit. I very recently implemented support
in mapserver to apply "true" classification to original >8bit rasters and this
would apply to GRASS rasters as well. One thing that does not work in MapServer
at this time is use of more than 256 colors in a color table taken from a
GDAL datasource. So if you want to render an integer grass coverage that
has more than 256 values you are still going to have a problem. I could look
into correcting this but it hasn't been high priority.
Then there is the more general question of whether I will be updating libgrass
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 it
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.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
Hello Frank,
At Sat, 13 Mar 2004 14:32:54 -0500 Frank Warmerdam wrote:
Thanks for your quick reply.
It what sense would you like to support >8bit rasters? The GDAL
access to GRASS rasters via libgrass already supports floating point
rasters, and integer rasters with >8 bit pixel data types. There may
(or may not, I'm not too sure) be a limit only 256 colors in the
driver though that isn't a requirements of GDAL.
Sorry for mixing things up. I meant the 256-value limit. I was trying to
display a DEM with more than 256 colors which appears all black...
There I realized the 256-value limit. After reclassifing the coverage
inside of GRASS everything shows up as expected.
Is the issue at the MapServer end? MapServer has supported >8bit
rasters for a while, but by scaling them to 8bit. I very recently
implemented support in mapserver to apply "true" classification to
original >8bit rasters and this would apply to GRASS rasters as well.
OK.
One thing that does not work in MapServer at this time is use of more
than 256 colors in a color table taken from a GDAL datasource. So if
you want to render an integer grass coverage that has more than 256
values you are still going to have a problem. I could look into
correcting this but it hasn't been high priority.
So the 256-color-limit is in GDAL? I am really interested in using my
GRASS-coverages with more than 256 values directly out of my location
without exporting them to e.g. tiff+tfw.
So direct map-calculations would be possible.
Then there is the more general question of whether I will be updating
libgrass 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 it 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.
That sounds good.
Anyway, thanks for bringing some light into this topic.
Cheers
Stephan Holl
--
Stephan Holl
Check headers for GnuPG Key!
http://www.gdf-hannover.de
11:41:27 up 26 min, 1 user, load average: 0.08, 0.02, 0.04
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
libgrass
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
it
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.
Frank,
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
G_close_cell
G_free
G_free_colors
x G_get_cell_as_proj4 - get_proj4_def.c
G_get_cellhd
G_get_color
G_get_fp_range_min_max
G_get_null_value_row
G_get_raster_row
x G_gisinit_2 - gisinit2.c
G_open_cell_old
G_read_colors
G_read_fp_range
G_set_error_routine
G_set_window
---------------
x: 3 new functions in libgrass
Maybe 2-4 underlying functions were also implemented.
suggestion:
Maybe move these few extra functions to
gdal/frmts/grass/
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.
Markus
Markus Neteler wrote:
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.
If you are considering releasing shared libraries as a standalone
package, we will have to start paying attention to version issues.
Specifically, each library will require a version number in its
soname, and that version number will need to increase whenever an
incompatible change is made to the library.
--
Glynn Clements <glynn.clements@virgin.net>
Markus Neteler wrote:
Frank,
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
G_close_cell
G_free
G_free_colors
x G_get_cell_as_proj4 - get_proj4_def.c
G_get_cellhd
G_get_color
G_get_fp_range_min_max
G_get_null_value_row
G_get_raster_row
x G_gisinit_2 - gisinit2.c
G_open_cell_old
G_read_colors
G_read_fp_range
G_set_error_routine
G_set_window
---------------
x: 3 new functions in libgrass
Markus,
Yes, it has always been my intention that libgrass would be superceeded
by shared libraries from GRASS itself. To do so, we would need to migrate
the functions added in libgrass to libgis (or somewhere else appropriate),
and perhaps work out a few issues to limit the amount of code an application
needs to link in to get GRASS support.
Note, the additions in libgrass were conceived of to make GRASS translators
easier to write and would apply to other targets than just GDAL. So I think
libgis would be the ideal eventual place for them.
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.
What is less clear to me (because I haven't been staying on top of GRASS status)
is whether we should be doing this work in 5.3 or 5.7. Does 5.3 overhaul the
build system and used shared libraries for libgis or is that only in 5.7?
I would add I don't forsee having time to work on this in the immediate future.
I see it more as an eventual objective.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
On Mon, Mar 15, 2004 at 12:43:28AM +0000, Glynn Clements wrote:
Markus Neteler wrote:
> 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.
If you are considering releasing shared libraries as a standalone
package, we will have to start paying attention to version issues.
Specifically, each library will require a version number in its
soname, and that version number will need to increase whenever an
incompatible change is made to the library.
Yes. Shouldn't the version number in the soname be added in
any case?
Markus
On Monday 15 March 2004 08:17, Frank Warmerdam wrote:
What is less clear to me (because I haven't been staying on top of GRASS
status) is whether we should be doing this work in 5.3 or 5.7.
In 5.7 it is already done, I believe.
Radim
On Mon, 15 Mar 2004, Glynn Clements wrote:
Markus Neteler wrote:
> 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.
If you are considering releasing shared libraries as a standalone
package, we will have to start paying attention to version issues.
Specifically, each library will require a version number in its
soname, and that version number will need to increase whenever an
incompatible change is made to the library.
As far as I can remember the code from Tcl that we copied into aclocal.m4
did have a facility for this but I didn't use it in 5.3 as to a certain
extent I was copying what Markus did for 5.7 to keep it simple.
The idea would be to use $(SHARED_LIB_SUFFIX) instead of $(SHLIB_SUFFIX)
but I'm sure it would be more complicated to implement than just changing
the variable name where it used in the Makefiles.
Markus Neteler wrote:
> > 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.
>
> If you are considering releasing shared libraries as a standalone
> package, we will have to start paying attention to version issues.
>
> Specifically, each library will require a version number in its
> soname, and that version number will need to increase whenever an
> incompatible change is made to the library.
Yes. Shouldn't the version number in the soname be added in
any case?
Ideally, shared libraries should be versioned. But there's no point
having a version number unless it actually means something. Adding a
version number which doesn't mean anything is worse than not having a
version number, as it may create a false sense of security.
Simply changing the soname of e.g. libgrass_gis from libgrass_gis.so
to libgrass_gis.so.0 would be trivial. The slightly more awkward part
is adding a version number to each library Gmakefile and changing
SLIBRULE to make use of it. The substantially more awkward part is
making sure that developers remember to increment the version number
whenever they make an incompatible change (and, preferably, not to
make incompatible changes too often).
--
Glynn Clements <glynn.clements@virgin.net>