[Geoserver-users] Loading Blue Marble Next Generation with tutorial

GeoServer GeoServer User
1

I'm trying to load NASA's BMNG data into Geoserver 1.6.4 following the tutorial available at http://geoserver.org/display/GEOSDOC/Load+NASA+Blue+Marble+Data . I get a NullPointerException trying to run the MosaicIndexBuilder on MosaicIndexBuilder.java:357:

    envelope = (GeneralEnvelope) reader.getOriginalEnvelope();

Reader is null because GeoTiffFormat doesn't initialize because the GeoTiffIIOMetadataDecoder says:

    GeoKey directory does not exist

I looked at the TIFF that gdal_translate made, and only these private tags were present:

    33550 (0x830e) DOUBLE (12) 3<0.00416667 0.00416667 0>
    33922 (0x8482) DOUBLE (12) 6<0 0 0 -180 1.44951e-012 0>

Does anyone know why gdal_translate left off the GeoKeyDirectoryTag and the other GeoTiff tags? What kind of workaround would be best?

--
Dustin Parker
Forward Slope, Inc.
Work: 619 299 4400
Cell: 619 277 2591
0tDaX0iWmunqkiR2WKCNG
vHUT0iWqSJHZYoI0a8d1p
E9Ilprp6QZrogbPZYoI0a
8aA0ekDQ6eyxQRo146A==

2

On Aug 21, 2008, at 1:15 PM, Dustin Parker wrote:

Does anyone know why gdal_translate left off the GeoKeyDirectoryTag and
the other GeoTiff tags? What kind of workaround would be best?

This doesn't answer your question directly, but I believe that I have read on this list that an internally tiled GeoTIFF with overviews will provide equivalent performance as an image pyramid in most cases. GDAL can build a GeoTIFF in this manner and GeoServer can read them. The main limitation is the size of the resulting GeoTIFF (4GB is usually the limit).

See below for more details:
http://geoserver.org/display/GEOSDOC/High+performance+coverage+serving

Cheers,
Ryan

3

Ryan Hofschneider wrote:

This doesn't answer your question directly, but I believe that I have read on this list that an internally tiled GeoTIFF with overviews will provide equivalent performance as an image pyramid in most cases. GDAL can build a GeoTIFF in this manner and GeoServer can read them. The main limitation is the size of the resulting GeoTIFF (4GB is usually the limit).

See below for more details:
http://geoserver.org/display/GEOSDOC/High+performance+coverage+serving

Cheers,
Ryan
  

Hello Ryan,

Thank you for the advice. We produced a 90°x90° window on the NASA imagery (21600x21600 pixels) with TIFF internal tiling turned on and overviews at 1/2, 1/4, 1/8, 1/16, and 1/32 resolutions and it takes at most one or two seconds to draw the whole coverage and even less time at small scales. This is down from at least a full minute for the full coverage with just the internal tiling turned on.

Just a note for anyone interested: I had to update our libtiff from 3.8 to 3.9 (CVS) and relink GDAL to use it. Before that, gdaladdo was having issues with the "StripByteCounts" field of our coverage and only produced black squares as overviews.

--
Dustin Parker
Forward Slope, Inc.
Work: 619 299 4400
Cell: 619 277 2591
0tDaX0iWmunqkiR2WKCNG
vHUT0iWqSJHZYoI0a8d1p
E9Ilprp6QZrogbPZYoI0a
8aA0ekDQ6eyxQRo146A==

4

Ciao Dustin,
please, read below...

On Fri, Aug 22, 2008 at 7:49 PM, Dustin Parker <dparker@anonymised.com> wrote:

Ryan Hofschneider wrote:

This doesn't answer your question directly, but I believe that I have
read on this list that an internally tiled GeoTIFF with overviews will
provide equivalent performance as an image pyramid in most cases. GDAL
can build a GeoTIFF in this manner and GeoServer can read them. The
main limitation is the size of the resulting GeoTIFF (4GB is usually
the limit).

See below for more details:
http://geoserver.org/display/GEOSDOC/High+performance+coverage+serving

Cheers,
Ryan

Hello Ryan,

Thank you for the advice. We produced a 90°x90° window on the NASA
imagery (21600x21600 pixels) with TIFF internal tiling turned on and
overviews at 1/2, 1/4, 1/8, 1/16, and 1/32 resolutions and it takes at
most one or two seconds to draw the whole coverage and even less time at
small scales.

I would add also 1/64 and probably 1/128. Moreover, you might want to
try to turn on JPEG compression at 75%.
Make sure the tile size is 512*512.

This is down from at least a full minute for the full
coverage with just the internal tiling turned on.

Without overviews you were forcing the reader to do decimation on the
fly at each requests from the full resolution layer, that's why it was
slow.
I would recommend you produce the 8 tiles with internal overview and
jpeg compression then you can build a tile index for them and
configure them as a mosaic.

Ciao,
Simone.

Just a note for anyone interested: I had to update our libtiff from 3.8
to 3.9 (CVS) and relink GDAL to use it. Before that, gdaladdo was
having issues with the "StripByteCounts" field of our coverage and only
produced black squares as overviews.

--
Dustin Parker
Forward Slope, Inc.
Work: 619 299 4400
Cell: 619 277 2591
0tDaX0iWmunqkiR2WKCNG
vHUT0iWqSJHZYoI0a8d1p
E9Ilprp6QZrogbPZYoI0a
8aA0ekDQ6eyxQRo146A==

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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

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