[Geoserver-users] Coveragestore not always visible in Openlayers

GeoServer GeoServer User
1

I’m noticing something that’s concerning me about the display of a GeoTIFF in OpenLayers. Take a look at:
http://68.178.124.166:8080/geoserver/wms?bbox=-180.0044642857,-89.99999999999997,179.99409571429993,89.99928&styles=&Format=application/openlayers&request=GetMap&layers=cite:countries_simple,cite:gdal_1_spam_glc2&width=800&height=375&srs=EPSG:4326

If you step up through each of the zoom levels, you’ll see ones where the raster layer doesn’t display at all. Then after you zoom in another level or two, it reappears. Is this part of known buggy Coveragestore behavior in this release of Geoserver, or is something else going on?

Thanks,

Roger

Roger André
GIS Developer/Analyst
Enterprise Management Solutions
CH2M HILL
Tel: 425.233.3042

2

Hi Roger,

I definitely see the problem. As for the cause I have no idea. Someone else will have a better idea though. What would help is more info about the geotiff. Is it built with overviews? is it tiled? etc... The output of gdalinfo would be useful.

-Justin

Roger Andre wrote:

I'm noticing something that's concerning me about the display of a GeoTIFF in OpenLayers. Take a look at:
http://68.178.124.166:8080/geoserver/wms?bbox=-180.0044642857,-89.99999999999997,179.99409571429993,89.99928&styles=&Format=application/openlayers&request=GetMap&layers=cite:countries_simple,cite:gdal_1_spam_glc2&width=800&height=375&srs=EPSG:4326

If you step up through each of the zoom levels, you'll see ones where the raster layer doesn't display at all. Then after you zoom in another level or two, it reappears. Is this part of known buggy Coveragestore behavior in this release of Geoserver, or is something else going on?

Thanks,

Roger
--
Roger André
GIS Developer/Analyst
Enterprise Management Solutions
CH2M HILL
Tel: 425.233.3042

!DSPAM:4007,47bd0cf9196126491211187!

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

!DSPAM:4007,47bd0cf9196126491211187!

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

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,47bd0cf9196126491211187!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

3

Hi Justin,

It’s a 4-band GeoTIFF with the 4th band serving as an Alpha layer. The original 3-band image was “classified” in Gimp, then converted into a 4-band GeoTiff with the following gdalwarp command:

gdalwarp -srcnodata “0 0 0” -dstalpha -s_srs “EPSG:4326” -t_srs “EPSG:4326” gimp_1_spam_glc2.tif gdal_1_spam_glc2.tif

  • gdalinfo output below:
    Driver: GTiff/GeoTIFF
    Files: gdal_1_spam_glc2.tif
    Size is 4320, 2160
    Coordinate System is:
    GEOGCS[“WGS 84”,
    DATUM[“WGS_1984”,
    SPHEROID[“WGS 84”,6378137,298.2572235629972,
    AUTHORITY[“EPSG”,“7030”]],
    AUTHORITY[“EPSG”,“6326”]],
    PRIMEM[“Greenwich”,0],
    UNIT[“degree”,0.0174532925199433],
    AUTHORITY[“EPSG”,“4326”]]
    Origin = (-180.004464285700010,89.999279999999999)
    Pixel Size = (0.083333000000000,-0.083333000000000)
    Metadata:
    AREA_OR_POINT=Area
    Image Structure Metadata:
    INTERLEAVE=PIXEL
    Corner Coordinates:
    Upper Left (-180.0044643, 89.9992800) (180d 0’16.07"W, 89d59’57.41"N)
    Lower Left (-180.0044643, -90.0000000) (180d 0’16.07"W, 90d 0’0.00"S)
    Upper Right ( 179.9940957, 89.9992800) (179d59’38.74"E, 89d59’57.41"N)
    Lower Right ( 179.9940957, -90.0000000) (179d59’38.74"E, 90d 0’0.00"S)
    Center ( -0.0051843, -0.0003600) ( 0d 0’18.66"W, 0d 0’1.30"S)
    Band 1 Block=4320x1 Type=Byte, ColorInterp=Red
    Mask Flags: PER_DATASET ALPHA
    Band 2 Block=4320x1 Type=Byte, ColorInterp=Green
    Mask Flags: PER_DATASET ALPHA
    Band 3 Block=4320x1 Type=Byte, ColorInterp=Blue
    Mask Flags: PER_DATASET ALPHA
    Band 4 Block=4320x1 Type=Byte, ColorInterp=Alpha

Thanks,

Roger

On Wed, Feb 20, 2008 at 10:26 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Roger,

I definitely see the problem. As for the cause I have no idea. Someone
else will have a better idea though. What would help is more info about
the geotiff. Is it built with overviews? is it tiled? etc… The output
of gdalinfo would be useful.

-Justin

Roger Andre wrote:

I’m noticing something that’s concerning me about the display of a
GeoTIFF in OpenLayers. Take a look at:
http://68.178.124.166:8080/geoserver/wms?bbox=-180.0044642857,-89.99999999999997,179.99409571429993,89.99928&styles=&Format=application/openlayers&request=GetMap&layers=cite:countries_simple,cite:gdal_1_spam_glc2&width=800&height=375&srs=EPSG:4326
<http://68.178.124.166:8080/geoserver/wms?bbox=-180.0044642857,-89.99999999999997,179.99409571429993,89.99928&styles=&Format=application/openlayers&request=GetMap&layers=cite:countries_simple,cite:gdal_1_spam_glc2&width=800&height=375&srs=EPSG:4326>

If you step up through each of the zoom levels, you’ll see ones where
the raster layer doesn’t display at all. Then after you zoom in another
level or two, it reappears. Is this part of known buggy Coveragestore
behavior in this release of Geoserver, or is something else going on?

Thanks,

Roger

Roger André
GIS Developer/Analyst
Enterprise Management Solutions
CH2M HILL
Tel: 425.233.3042

!DSPAM:4007,47bd0cf9196126491211187!

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

!DSPAM:4007,47bd0cf9196126491211187!

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,47bd0cf9196126491211187!

–
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

4

Hi Roger,

I could try to play with your geotiff next week when I back to work.
Is there a way to obtain that tested geotiff (somewhere on ftp, or by some
other way) so I can setup a geoserver and debug the test case?

Let me know (I will be away until sunday).
Regards,
Daniele Romagnoli

Roger.Andre wrote:

Hi Justin,

It's a 4-band GeoTIFF with the 4th band serving as an Alpha layer. The
original 3-band image was "classified" in Gimp, then converted into a
4-band
GeoTiff with the following gdalwarp command:

gdalwarp -srcnodata "0 0 0" -dstalpha -s_srs "EPSG:4326" -t_srs
"EPSG:4326"
gimp_1_spam_glc2.tif gdal_1_spam_glc2.tif

- gdalinfo output below:
Driver: GTiff/GeoTIFF
Files: gdal_1_spam_glc2.tif
Size is 4320, 2160
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.2572235629972,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-180.004464285700010,89.999279999999999)
Pixel Size = (0.083333000000000,-0.083333000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left (-180.0044643, 89.9992800) (180d 0'16.07"W, 89d59'57.41"N)
Lower Left (-180.0044643, -90.0000000) (180d 0'16.07"W, 90d 0'0.00"S)
Upper Right ( 179.9940957, 89.9992800) (179d59'38.74"E, 89d59'57.41"N)
Lower Right ( 179.9940957, -90.0000000) (179d59'38.74"E, 90d 0'0.00"S)
Center ( -0.0051843, -0.0003600) ( 0d 0'18.66"W, 0d 0'1.30"S)
Band 1 Block=4320x1 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA
Band 2 Block=4320x1 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA
Band 3 Block=4320x1 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA
Band 4 Block=4320x1 Type=Byte, ColorInterp=Alpha

--
View this message in context: http://www.nabble.com/Coveragestore-not-always-visible-in-Openlayers-tp15605135p15614711.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

5

Just a quick follow-up about this, I believe the problem is being caused by an out-of-memory condition in Java. I cleared the log and was able to repeat the raster display problem in OpenLayers. I get the following entry in the log file when this happens:

2008-02-25 10:21:37,243 WARN [geotools.rendering] - Java heap space
java.lang.OutOfMemoryError: Java heap space

I’m going to try and implement the recommendation found on http://docs.codehaus.org/display/GEOSDOC/5+Optimizing+WMS+output to display the image in jpeg format, but I’m still a bit concerned by this. Are there other things I can do to make more memory available to Java, so that I can avoid this error in the future?

Roger

On Thu, Feb 21, 2008 at 9:16 AM, Daniele Romagnoli <dany.geotools@anonymised.com> wrote:

Hi Roger,

I could try to play with your geotiff next week when I back to work.
Is there a way to obtain that tested geotiff (somewhere on ftp, or by some
other way) so I can setup a geoserver and debug the test case?

Let me know (I will be away until sunday).
Regards,
Daniele Romagnoli

Roger.Andre wrote:

Hi Justin,

It’s a 4-band GeoTIFF with the 4th band serving as an Alpha layer. The
original 3-band image was “classified” in Gimp, then converted into a
4-band
GeoTiff with the following gdalwarp command:

gdalwarp -srcnodata “0 0 0” -dstalpha -s_srs “EPSG:4326” -t_srs
“EPSG:4326”
gimp_1_spam_glc2.tif gdal_1_spam_glc2.tif

  • gdalinfo output below:
    Driver: GTiff/GeoTIFF
    Files: gdal_1_spam_glc2.tif
    Size is 4320, 2160
    Coordinate System is:
    GEOGCS[“WGS 84”,
    DATUM[“WGS_1984”,
    SPHEROID[“WGS 84”,6378137,298.2572235629972,
    AUTHORITY[“EPSG”,“7030”]],
    AUTHORITY[“EPSG”,“6326”]],
    PRIMEM[“Greenwich”,0],
    UNIT[“degree”,0.0174532925199433],
    AUTHORITY[“EPSG”,“4326”]]
    Origin = (-180.004464285700010,89.999279999999999)
    Pixel Size = (0.083333000000000,-0.083333000000000)
    Metadata:
    AREA_OR_POINT=Area
    Image Structure Metadata:
    INTERLEAVE=PIXEL
    Corner Coordinates:
    Upper Left (-180.0044643, 89.9992800) (180d 0’16.07"W, 89d59’57.41"N)
    Lower Left (-180.0044643, -90.0000000) (180d 0’16.07"W, 90d 0’0.00"S)
    Upper Right ( 179.9940957, 89.9992800) (179d59’38.74"E, 89d59’57.41"N)
    Lower Right ( 179.9940957, -90.0000000) (179d59’38.74"E, 90d 0’0.00"S)
    Center ( -0.0051843, -0.0003600) ( 0d 0’18.66"W, 0d 0’1.30"S)
    Band 1 Block=4320x1 Type=Byte, ColorInterp=Red
    Mask Flags: PER_DATASET ALPHA
    Band 2 Block=4320x1 Type=Byte, ColorInterp=Green
    Mask Flags: PER_DATASET ALPHA
    Band 3 Block=4320x1 Type=Byte, ColorInterp=Blue
    Mask Flags: PER_DATASET ALPHA
    Band 4 Block=4320x1 Type=Byte, ColorInterp=Alpha

–
View this message in context: http://www.nabble.com/Coveragestore-not-always-visible-in-Openlayers-tp15605135p15614711.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–
Roger André
GIS Developer/Analyst
Enterprise Management Solutions
CH2M HILL
Tel: 425.233.3042

6

Roger Andre ha scritto:

Just a quick follow-up about this, I believe the problem is being caused by an out-of-memory condition in Java. I cleared the log and was able to repeat the raster display problem in OpenLayers. I get the following entry in the log file when this happens:

2008-02-25 10:21:37,243 WARN [geotools.rendering] - Java heap space
java.lang.OutOfMemoryError: Java heap space

I'm going to try and implement the recommendation found on http://docs.codehaus.org/display/GEOSDOC/5+Optimizing+WMS+output to display the image in jpeg format, but I'm still a bit concerned by this. Are there other things I can do to make more memory available to Java, so that I can avoid this error in the future?

Encoding in JPEG will optimize speed but not memory usage. For memory
and JVM related issues I'd suggest you have a look at:
http://geoserver.org/display/GEOSDOC/6+GeoServer+in+Production+Environment

Cheers
Andrea