[Geoserver-users] FW: Response Geotiff comparisons between Geoserver 2.2.4 and 2.5

GeoServer GeoServer User
1

When I did the following request,
/geoserver/imagery/wcs?service=WCS&version=1.1.1&request=GetCoverage&identifier=goes_13.IR.1km&BoundingBox=-101.30696,-31.566105,-86.18939,2.4446182,urn:ogc:def:crs:OGC:1.3:CRS84&format=geotiff

I noticed differing metadata information when I do a gdalinfo on the returned decoded tiff file. (Attached above.)

The main differences being that
For 2.2.4,

  • the width/height is 414x931 (as expected, since it’s a slice of the original 2055x3562 image)
  • the Band 1 Block=256x256
  • the corner coordinates are correct
    For 2.5,
  • the width/height is 2055x4624 (the original being 2055x3562)
  • the Band 1 Block=2055x19
  • the corner coordinates lon/lat values are swapped

Does anyone know if there is some configuration with the tile sizing that was done for Geoserver 2.2.4 that we missed for Geoserver 2.5? The large Band Block sizes are large (i.e. 8220x14 for a 8220x974 image) even when we directly bypass the satellite coverage plugin and request it through Geoserver 2.5’s built-in GeoTIFF plugin.

Any insight will be helpful.

Thanks,
Kristine

geotiff-ashoreci.PNG

geotiff-ashore44.PNG

2

Interesting, can I ask you to double check which answer is correct? For WCS it is likely that the result is expected in lat / lon order (in which case this change represents an issue being fixed).

···

Jody Garnett

On Thu, Jul 31, 2014 at 1:50 PM, Bessette-Halsema, Dominique E <Dominique.Bessette@anonymised.com> wrote:

When I did the following request,
/geoserver/imagery/wcs?service=WCS&version=1.1.1&request=GetCoverage&identifier=goes_13.IR.1km&BoundingBox=-101.30696,-31.566105,-86.18939,2.4446182,urn:ogc:def:crs:OGC:1.3:CRS84&format=geotiff

I noticed differing metadata information when I do a gdalinfo on the returned decoded tiff file. (Attached above.)

The main differences being that
For 2.2.4,

  • the width/height is 414x931 (as expected, since it’s a slice of the original 2055x3562 image)
  • the Band 1 Block=256x256
  • the corner coordinates are correct
    For 2.5,
  • the width/height is 2055x4624 (the original being 2055x3562)
  • the Band 1 Block=2055x19
  • the corner coordinates lon/lat values are swapped

Does anyone know if there is some configuration with the tile sizing that was done for Geoserver 2.2.4 that we missed for Geoserver 2.5? The large Band Block sizes are large (i.e. 8220x14 for a 8220x974 image) even when we directly bypass the satellite coverage plugin and request it through Geoserver 2.5’s built-in GeoTIFF plugin.

Any insight will be helpful.

Thanks,
Kristine

Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk

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

3

I’m not quite sure I understand the response from Jody. If she’s asking about the corner coordinates, then yes, they are in lat/lon order, i.e.

Corner Coordinates:
Upper Left ( 2.445, -101.307) ( 2d26’40.63"E,101d18’25.06"S)
Lower Left ( -31.566, -101.307) ( 31d33’57.98"W,101d18’25.06"S)
Upper Right ( 2.4446182, -86.1893900) ( 2d26’40.63"E, 86d11’21.80"S)
Lower Right ( -31.5661050, -86.1893900) ( 31d33’57.98"W, 86d11’21.80"S)
Center ( -14.561, -93.748) ( 14d33’38.68"W, 93d44’53.43"S)

The bigger concern is why making a WCS 1.1.1 getCoverage request with the full bounding box (-120.0038771,-65.0093883,-44.9961229,65.0093883) will result in an image of width/height 2055x3562 (as expected, the size of the original tiff), whereas giving a smaller bounding box (-101.30696,-31.566105,-86.18939,2.4446182) gives a response scaled to the original width resulting in an image of w/h 2055x4624 (instead of 414x931, as expected). Is this by design to scale the response to its original width?

Thanks.

···

Interesting, can I ask you to double check which answer is correct? For WCS it is likely that the result is expected in lat / lon order (in which case this change represents an issue being fixed).

Jody Garnett

On Thu, Jul 31, 2014 at 1:50 PM, Bessette-Halsema, Dominique E <Dominique.Bessette@…1196…> wrote:

When I did the following request,
/geoserver/imagery/wcs?service=WCS&version=1.1.1&request=GetCoverage&identifier=goes_13.IR.1km&BoundingBox=-101.30696,-31.566105,-86.18939,2.4446182,urn:ogc:def:crs:OGC:1.3:CRS84&format=geotiff

I noticed differing metadata information when I do a gdalinfo on the returned decoded tiff file. (Attached above.)

The main differences being that
For 2.2.4,

  • the width/height is 414x931 (as expected, since it’s a slice of the original 2055x3562 image)
  • the Band 1 Block=256x256
  • the corner coordinates are correct
    For 2.5,
  • the width/height is 2055x4624 (the original being 2055x3562)
  • the Band 1 Block=2055x19
  • the corner coordinates lon/lat values are swapped

Does anyone know if there is some configuration with the tile sizing that was done for Geoserver 2.2.4 that we missed for Geoserver 2.5? The large Band Block sizes are large (i.e. 8220x14 for a 8220x974 image) even when we directly bypass the satellite coverage plugin and request it through Geoserver 2.5’s built-in GeoTIFF plugin.

Any insight will be helpful.

Thanks,
Kristine

Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk

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

4

Hi,

we will take a look at the code to investigate on that.

Do you have any chance to share your sample data? (even by private email)

Regards,

Daniele

···

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

On Thu, Jul 31, 2014 at 10:50 PM, Bessette-Halsema, Dominique E <Dominique.Bessette@anonymised.com> wrote:

When I did the following request,
/geoserver/imagery/wcs?service=WCS&version=1.1.1&request=GetCoverage&identifier=goes_13.IR.1km&BoundingBox=-101.30696,-31.566105,-86.18939,2.4446182,urn:ogc:def:crs:OGC:1.3:CRS84&format=geotiff

I noticed differing metadata information when I do a gdalinfo on the returned decoded tiff file. (Attached above.)

The main differences being that
For 2.2.4,

  • the width/height is 414x931 (as expected, since it’s a slice of the original 2055x3562 image)
  • the Band 1 Block=256x256
  • the corner coordinates are correct
    For 2.5,
  • the width/height is 2055x4624 (the original being 2055x3562)
  • the Band 1 Block=2055x19
  • the corner coordinates lon/lat values are swapped

Does anyone know if there is some configuration with the tile sizing that was done for Geoserver 2.2.4 that we missed for Geoserver 2.5? The large Band Block sizes are large (i.e. 8220x14 for a 8220x974 image) even when we directly bypass the satellite coverage plugin and request it through Geoserver 2.5’s built-in GeoTIFF plugin.

Any insight will be helpful.

Thanks,
Kristine

Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk

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