[Geoserver-users] Problems with Transparency in raster layers

Hi,

I´m using the ImageMosaic plugin (WCS branch) to built a coverage based on
Geotiffs. The index shapefile was created using Gdal and it went with no
probs. The situation is that when I display the coverage in Geoserver is was
supposed to be transparent, therefore the pixels with no data shouldn't be
displayed, but they come out in color black.

When i tried to use this layer on a map, i passed the parameter
'transparent=true' to the wms client (OpenLayers) and the layer does come
out transparent except the area (bounding box) covered by the shapefile.

Here are the parameters:
http://localhost:8080/geoserver/wms?bbox=-33597.036667,95999.973333,-25597.316333,104999.907667&styles=&Format=application/openlayers&request=GetMap&layers=gir:map_1&width=539&height=550&srs=EPSG:27492

I tried to change formats between png and gif, but same happens.

Maybe the problem is with the raster SLD, if i have to indicate, using some
descriptor, that 'No Data' pixels has to come out transparent...i don't
know. even when i tried to apply the default raster SLD the raster layer
turns out white! i´m slamming my head with this for about one week...

Thx in advance!

Pedro Mendes
--
View this message in context: http://www.nabble.com/Problems-with-Transparency-in-raster-layers-tf4367514.html#a12448502
Sent from the GeoServer - User mailing list archive at Nabble.com.

Pedro Mendes ha scritto:

Hi,

I´m using the ImageMosaic plugin (WCS branch) to built a coverage based on
Geotiffs. The index shapefile was created using Gdal and it went with no
probs. The situation is that when I display the coverage in Geoserver is was
supposed to be transparent, therefore the pixels with no data shouldn't be
displayed, but they come out in color black.

Hum... WCS branch? You mean you're using GeoServer 1.4.x WCS branch instead of the latest 1.5.3? That branch was experimental anyways.

If so, try upgrading GeoServer to 1.5.3.
If not, then maybe you're hitting a bug in GeoServer. Could you
provide us with a sample of your coverages (2-3, just enough to reproduce the issue).

I've cc'ed Alessio and Simone, the mosaic plugin developers, maybe they
do know more.

Cheers
Andrea

Hi aaime,

I´m using geoserver version 1.5.3. Here it is the output image result of the
getMap request:

http://www.nabble.com/file/p12465985/coverage1.png

http://www.nabble.com/file/p12465985/coverage2.png

http://www.nabble.com/file/p12465985/coverage3.png

has u see, all the pixels that aren´t from the renderized .tif (.tfw) files
that built the shapefile, and going to the bounding box limits, come out
black. In further tests with the raster.sld, I just acomplished some
transparency changing opacity value to lower levels, but the "black/grey"
pixels in that areas continues.

I tried to passe the parameter transparent='true' and bgcolor='0xFFFFFF' for
the wms request and still remain the same display.

where it is the info.xml from the coverage:

http://www.nabble.com/file/p12465985/info.xml info.xml

I think maybe the jar files responsable for the image rendering (JAI)
weren't doing it right for the tif files..

Cumps,
Pedro Mendes

aaime wrote:

Pedro Mendes ha scritto:

Hi,

I´m using the ImageMosaic plugin (WCS branch) to built a coverage based
on
Geotiffs. The index shapefile was created using Gdal and it went with no
probs. The situation is that when I display the coverage in Geoserver is
was
supposed to be transparent, therefore the pixels with no data shouldn't
be
displayed, but they come out in color black.

Hum... WCS branch? You mean you're using GeoServer 1.4.x WCS branch
instead of the latest 1.5.3? That branch was experimental anyways.

If so, try upgrading GeoServer to 1.5.3.
If not, then maybe you're hitting a bug in GeoServer. Could you
provide us with a sample of your coverages (2-3, just enough to
reproduce the issue).

I've cc'ed Alessio and Simone, the mosaic plugin developers, maybe they
do know more.

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://www.nabble.com/Problems-with-Transparency-in-raster-layers-tf4367514.html#a12465985
Sent from the GeoServer - User mailing list archive at Nabble.com.

Ciao Pedro,
please, read below...

On 9/3/07, Pedro Mendes <mendes@anonymised.com> wrote:

Hi,

I´m using the ImageMosaic plugin (WCS branch) to built a coverage based on
Geotiffs. The index shapefile was created using Gdal and it went with no
probs.

Well, using gdaltindex is not always sufficient in order to build the
index for the mosaic plugin. The MosaicIndexBuilder utility does not
only create the index shapefile for the mosaic but it also creates a
properties file used to check various things. In this special case I
suspect that your tiff files are paletted but each of them is using a
different palette, hence a color expansion must be performed prior to
mosaicking them. The ImageMosaic plugin relies on the properties files
created by the MosaicIndexBuilder to spot such a situation. If you
created the file by hand without adding the proper tags, well things
can get pretty messed up.

For reference see http://jira.codehaus.org/browse/GEOS-1109:

Just to make sure that this is the cause of your problems, please,
send two of your tif fifles or simply paste here the result of fthe
gdalinfo on them. Best thing to do would probably be building the
index using the MosaicIndexBuilder.

The situation is that when I display the coverage in Geoserver is was
supposed to be transparent, therefore the pixels with no data shouldn't be
displayed, but they come out in color black.

When i tried to use this layer on a map, i passed the parameter
'transparent=true' to the wms client (OpenLayers) and the layer does come
out transparent except the area (bounding box) covered by the shapefile.

Here are the parameters:
http://localhost:8080/geoserver/wms?bbox=-33597.036667,95999.973333,-25597.316333,104999.907667&styles=&Format=application/openlayers&request=GetMap&layers=gir:map_1&width=539&height=550&srs=EPSG:27492

I tried to change formats between png and gif, but same happens.

The output format has not much to do with this issue.

Maybe the problem is with the raster SLD, if i have to indicate, using some
descriptor, that 'No Data' pixels has to come out transparent...i don't
know. even when i tried to apply the default raster SLD the raster layer
turns out white! i´m slamming my head with this for about one week...

No please, don't do that but post messages instead :slight_smile: !

I am pretty sure that your problem will vanish once you build the
index correctly. If it turns out to be a bug, we'll fix it
(hopefully!).

Ciao,
Simone.

Thx in advance!

Pedro Mendes
--
View this message in context: http://www.nabble.com/Problems-with-Transparency-in-raster-layers-tf4367514.html#a12448502
Sent from the GeoServer - User mailing list archive at Nabble.com.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

Hi again,

well i'll follow ur advice and built the index using MosaicIndexBuilder
utility. i already tried once, but i had some issues (that i couldn't
overcome) building and configuring the project as told to compile... i'll
try again.

Gdalinfo on two tifs

#1
Driver: GTiff/GeoTIFF
Size is 9448, 5905
Coordinate System is `'
Origin = (-39996.992333333335000,104999.637333333350000)
Pixel Size = (0.846666666666667,-0.846666666666667)
Image Structure Metadata:
  COMPRESSION=CCITTFAX4
Corner Coordinates:
Upper Left ( -39996.992, 104999.637)
Lower Left ( -39996.992, 100000.071)
Upper Right ( -31997.686, 104999.637)
Lower Right ( -31997.686, 100000.071)
Center ( -35997.339, 102499.854)
Band 1 Block=9448x6 Type=Byte, ColorInterp=Palette
  Metadata:
    NBITS=1
  Color Table (RGB with 2 entries)
    0: 255,255,255,255
    1: 0,0,0,255

#2
Driver: GTiff/GeoTIFF
Size is 9448, 5905
Coordinate System is `'
Origin = (-31997.048333333332000,104999.541333333340000)
Pixel Size = (0.846666666666667,-0.846666666666667)
Image Structure Metadata:
  COMPRESSION=CCITTFAX4
Corner Coordinates:
Upper Left ( -31997.048, 104999.541)
Lower Left ( -31997.048, 99999.975)
Upper Right ( -23997.742, 104999.541)
Lower Right ( -23997.742, 99999.975)
Center ( -27997.395, 102499.758)
Band 1 Block=9448x6 Type=Byte, ColorInterp=Palette
  Metadata:
    NBITS=1
  Color Table (RGB with 2 entries)
    0: 255,255,255,255
    1: 0,0,0,255

this file contains the result of gdalinfo on 5 tifs that make the shape:
http://www.nabble.com/file/p12475568/tifs_gdalinfo.txt tifs_gdalinfo.txt

i'll send to the .prj and .properties files to complete:
http://www.nabble.com/file/p12475568/aveiroEscala0.properties
aveiroEscala0.properties

i really don't know if the index is built incorrectly because i made a
little experiment using mapserver to show a layer for this shapefile index
and the result was good. But it´s my objective to use geoserver for this
task so i have to get it done. =)

Cumps,

Pedro

--
View this message in context: http://www.nabble.com/Problems-with-Transparency-in-raster-layers-tf4367514.html#a12475568
Sent from the GeoServer - User mailing list archive at Nabble.com.

Ciao Pedro,
from what I saw all the files share the same palette. Make a last
attempt adding the ExpandToRGB=true line to the properties file. If
this does not solve the issue I am afraid I would need to take a look
at your data (or some sort of sample) to reproduce the problem here
and fix it.

Let me know,
Simone.
On 9/4/07, Pedro Mendes <mendes@anonymised.com> wrote:

Hi again,

well i'll follow ur advice and built the index using MosaicIndexBuilder
utility. i already tried once, but i had some issues (that i couldn't
overcome) building and configuring the project as told to compile... i'll
try again.

Gdalinfo on two tifs

#1
Driver: GTiff/GeoTIFF
Size is 9448, 5905
Coordinate System is `'
Origin = (-39996.992333333335000,104999.637333333350000)
Pixel Size = (0.846666666666667,-0.846666666666667)
Image Structure Metadata:
COMPRESSION=CCITTFAX4
Corner Coordinates:
Upper Left ( -39996.992, 104999.637)
Lower Left ( -39996.992, 100000.071)
Upper Right ( -31997.686, 104999.637)
Lower Right ( -31997.686, 100000.071)
Center ( -35997.339, 102499.854)
Band 1 Block=9448x6 Type=Byte, ColorInterp=Palette
Metadata:
   NBITS=1
Color Table (RGB with 2 entries)
   0: 255,255,255,255
   1: 0,0,0,255

#2
Driver: GTiff/GeoTIFF
Size is 9448, 5905
Coordinate System is `'
Origin = (-31997.048333333332000,104999.541333333340000)
Pixel Size = (0.846666666666667,-0.846666666666667)
Image Structure Metadata:
COMPRESSION=CCITTFAX4
Corner Coordinates:
Upper Left ( -31997.048, 104999.541)
Lower Left ( -31997.048, 99999.975)
Upper Right ( -23997.742, 104999.541)
Lower Right ( -23997.742, 99999.975)
Center ( -27997.395, 102499.758)
Band 1 Block=9448x6 Type=Byte, ColorInterp=Palette
Metadata:
   NBITS=1
Color Table (RGB with 2 entries)
   0: 255,255,255,255
   1: 0,0,0,255

this file contains the result of gdalinfo on 5 tifs that make the shape:
http://www.nabble.com/file/p12475568/tifs_gdalinfo.txt tifs_gdalinfo.txt

i'll send to the .prj and .properties files to complete:
http://www.nabble.com/file/p12475568/aveiroEscala0.properties
aveiroEscala0.properties

i really don't know if the index is built incorrectly because i made a
little experiment using mapserver to show a layer for this shapefile index
and the result was good. But it´s my objective to use geoserver for this
task so i have to get it done. =)

Cumps,

Pedro

--
View this message in context: http://www.nabble.com/Problems-with-Transparency-in-raster-layers-tf4367514.html#a12475568
Sent from the GeoServer - User mailing list archive at Nabble.com.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

Hi,

Building the index with MosaicIndexBuilder didn´t solve this issue either.
it still return black for the pixels with no data.

I have a doubt concerning MosaicIndexBuilder: i have already the index's
projection file made up, why it is necessary the create the .prj file for
each raster (with the same data) so the index could be built correctly?
There any chance passing a argument identifying the .prj as the projection
for all rasters?

Cumps, Pedro

Simone.Giannecchini wrote:

Ciao Pedro,
from what I saw all the files share the same palette. Make a last
attempt adding the ExpandToRGB=true line to the properties file. If
this does not solve the issue I am afraid I would need to take a look
at your data (or some sort of sample) to reproduce the problem here
and fix it.

Let me know,
Simone.
On 9/4/07, Pedro Mendes <mendes@anonymised.com> wrote:

Hi again,

well i'll follow ur advice and built the index using MosaicIndexBuilder
utility. i already tried once, but i had some issues (that i couldn't
overcome) building and configuring the project as told to compile... i'll
try again.

Gdalinfo on two tifs

#1
Driver: GTiff/GeoTIFF
Size is 9448, 5905
Coordinate System is `'
Origin = (-39996.992333333335000,104999.637333333350000)
Pixel Size = (0.846666666666667,-0.846666666666667)
Image Structure Metadata:
COMPRESSION=CCITTFAX4
Corner Coordinates:
Upper Left ( -39996.992, 104999.637)
Lower Left ( -39996.992, 100000.071)
Upper Right ( -31997.686, 104999.637)
Lower Right ( -31997.686, 100000.071)
Center ( -35997.339, 102499.854)
Band 1 Block=9448x6 Type=Byte, ColorInterp=Palette
Metadata:
   NBITS=1
Color Table (RGB with 2 entries)
   0: 255,255,255,255
   1: 0,0,0,255

#2
Driver: GTiff/GeoTIFF
Size is 9448, 5905
Coordinate System is `'
Origin = (-31997.048333333332000,104999.541333333340000)
Pixel Size = (0.846666666666667,-0.846666666666667)
Image Structure Metadata:
COMPRESSION=CCITTFAX4
Corner Coordinates:
Upper Left ( -31997.048, 104999.541)
Lower Left ( -31997.048, 99999.975)
Upper Right ( -23997.742, 104999.541)
Lower Right ( -23997.742, 99999.975)
Center ( -27997.395, 102499.758)
Band 1 Block=9448x6 Type=Byte, ColorInterp=Palette
Metadata:
   NBITS=1
Color Table (RGB with 2 entries)
   0: 255,255,255,255
   1: 0,0,0,255

this file contains the result of gdalinfo on 5 tifs that make the shape:
http://www.nabble.com/file/p12475568/tifs_gdalinfo.txt tifs_gdalinfo.txt

i'll send to the .prj and .properties files to complete:
http://www.nabble.com/file/p12475568/aveiroEscala0.properties
aveiroEscala0.properties

i really don't know if the index is built incorrectly because i made a
little experiment using mapserver to show a layer for this shapefile
index
and the result was good. But it´s my objective to use geoserver for this
task so i have to get it done. =)

Cumps,

Pedro

--
View this message in context:
http://www.nabble.com/Problems-with-Transparency-in-raster-layers-tf4367514.html#a12475568
Sent from the GeoServer - User mailing list archive at Nabble.com.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://www.nabble.com/Problems-with-Transparency-in-raster-layers-tf4367514.html#a12498251
Sent from the GeoServer - User mailing list archive at Nabble.com.

Pedro Mendes ha scritto:

Hi,

Building the index with MosaicIndexBuilder didn´t solve this issue either.
it still return black for the pixels with no data.

I have a doubt concerning MosaicIndexBuilder: i have already the index's
projection file made up, why it is necessary the create the .prj file for
each raster (with the same data) so the index could be built correctly?
There any chance passing a argument identifying the .prj as the projection
for all rasters?

Pedro,
in this case we really need some access to at least 3 of your original files to make up a test mosaic and reproduce the behaviour on our machines, debug it and hopefully fix it.
You can send them to Simone by private mail or (better) put them on
a ftp/http site and give him the address.

Cheers
Andrea