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