[GRASS5] status of libgrass, mapserver, gdal and >8bit rasters

Stephan Holl sholl at gmx.net
Sun Mar 14 05:59:51 EST 2004

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. 


> 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.

  Stephan Holl

Stephan Holl

Check headers for GnuPG Key!

 11:41:27 up 26 min,  1 user,  load average: 0.08, 0.02, 0.04
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040314/1978cdd0/attachment.bin

More information about the grass-dev mailing list