Offset/wrong bounding box

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Offset/wrong bounding box

Trey Stafford
Hello,

I have recently attempted upgrading my version of GeoServer from v2.10.1
(Ubuntu Linux 16.04.2 LTS) to v2.11.1. Although the upgrade went
smoothly, I am now observing an offset in the bounding box Geoserver
appears to be using for my image layers. I have tested this problem on
versions 2.10.2, 2.10.3, and 2.11.1. The problem appears in versions
after 2.10.2.

My layers are configured to use EPSG 3411 (NSIDC Sea Ice Polar
Stereographic North), and I have confirmed that the projection
definition remains the same between the versions that I have tested.

My problem is apparent with a simple WMS request to get the full layer,
using its configured bounds. When requested using v2.10.1, the image
looks as expected (see correct.png, attached). When requested using
versions after 2.10.2, geoserver seems to get these bounds wrong (see
incorrect.png). I also see this problem when I request the image as a
GeoTIFF using a WCS GetCoverage request. The GeoTiff downloaded via WCS
is correctly referenced (I can pull it into QGIS just fine), but still
only contains the 'offset' parts from the original image.

I observe this offset problem with both image mosaics and single image
GeoTiff stores.

gdalinfo output for the image featured in the attached images is below:

Driver: GTiff/GeoTIFF
Files: 20170620_N_20170620_extent_v2.1.tif
Size is 304, 448
Coordinate System is:
LOCAL_CS["NSIDC Sea Ice Polar Stereographic North",
     GEOGCS["Unspecified datum based upon the Hughes 1980 ellipsoid",
         DATUM["unknown",
             SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
         PRIMEM["Greenwich",0],
         UNIT["degree",0.0174532925199433]],
     AUTHORITY["EPSG","3411"],
     UNIT["metre",1,
         AUTHORITY["EPSG","9001"]]]
Origin = (-3850000.000000000000000,5850000.000000000000000)
Pixel Size = (25000.000000000000000,-25000.000000000000000)
Metadata:
   AREA_OR_POINT=Area
Image Structure Metadata:
   INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-3850000.000, 5850000.000)
Lower Left  (-3850000.000,-5350000.000)
Upper Right ( 3750000.000, 5850000.000)
Lower Right ( 3750000.000,-5350000.000)
Center      (  -50000.000,  250000.000)
Band 1 Block=304x26 Type=Byte, ColorInterp=Gray
   NoData Value=255

Here is the gdalinfo output from the geoTiff obtained from a WCS
GetCoverage request from geoserver v2.10.3:

Driver: GTiff/GeoTIFF
Files: /home/trst2284/Downloads/NSIDC-TEST_MOSAIC.tif
Size is 296, 360
Coordinate System is:
LOCAL_CS["unnamed",
     GEOGCS["unknown",
         DATUM["unknown",
             SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
         PRIMEM["Greenwich",0],
         UNIT[,0.0174532925199433]],
     AUTHORITY["EPSG","3411"],
     UNIT["unknown",1]]
Origin = (-3650000.000000000000000,3650000.000000000000000)
Pixel Size = (25000.000000000000000,-25000.000000000000000)
Metadata:
   AREA_OR_POINT=Area
   TIFFTAG_RESOLUTIONUNIT=1 (unitless)
   TIFFTAG_XRESOLUTION=1
   TIFFTAG_YRESOLUTION=1
Image Structure Metadata:
   INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-3650000.000, 3650000.000)
Lower Left  (-3650000.000,-5350000.000)
Upper Right ( 3750000.000, 3650000.000)
Lower Right ( 3750000.000,-5350000.000)
Center      (   50000.000, -850000.000)
Band 1 Block=304x368 Type=Byte, ColorInterp=Gray
   NoData Value=0


Any suggestions on how I might resolve this problem would be
appreciated! I have not come across any bug reports that seem to have
this same problem, but I'll be happy to submit one if this ends up being
a bug.

Thanks!

Trey Stafford


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

correct.png (16K) Download Attachment
incorrect.png (22K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Offset/wrong bounding box

Trey Stafford
All,

I appear to have attached the wrong example images (the previous ones
were from a separate issue which seems to be resolved with v2.10.3). You
will find the correct images attached to this reply.

My apologies for any confusion this may have caused!

Thanks again,

Trey


On 06/21/2017 04:28 PM, Trey Stafford wrote:

> Hello,
>
> I have recently attempted upgrading my version of GeoServer from
> v2.10.1 (Ubuntu Linux 16.04.2 LTS) to v2.11.1. Although the upgrade
> went smoothly, I am now observing an offset in the bounding box
> Geoserver appears to be using for my image layers. I have tested this
> problem on versions 2.10.2, 2.10.3, and 2.11.1. The problem appears in
> versions after 2.10.2.
>
> My layers are configured to use EPSG 3411 (NSIDC Sea Ice Polar
> Stereographic North), and I have confirmed that the projection
> definition remains the same between the versions that I have tested.
>
> My problem is apparent with a simple WMS request to get the full
> layer, using its configured bounds. When requested using v2.10.1, the
> image looks as expected (see correct.png, attached). When requested
> using versions after 2.10.2, geoserver seems to get these bounds wrong
> (see incorrect.png). I also see this problem when I request the image
> as a GeoTIFF using a WCS GetCoverage request. The GeoTiff downloaded
> via WCS is correctly referenced (I can pull it into QGIS just fine),
> but still only contains the 'offset' parts from the original image.
>
> I observe this offset problem with both image mosaics and single image
> GeoTiff stores.
>
> gdalinfo output for the image featured in the attached images is below:
>
> Driver: GTiff/GeoTIFF
> Files: 20170620_N_20170620_extent_v2.1.tif
> Size is 304, 448
> Coordinate System is:
> LOCAL_CS["NSIDC Sea Ice Polar Stereographic North",
>     GEOGCS["Unspecified datum based upon the Hughes 1980 ellipsoid",
>         DATUM["unknown",
>             SPHEROID["unretrievable - using
> WGS84",6378137,298.257223563]],
>         PRIMEM["Greenwich",0],
>         UNIT["degree",0.0174532925199433]],
>     AUTHORITY["EPSG","3411"],
>     UNIT["metre",1,
>         AUTHORITY["EPSG","9001"]]]
> Origin = (-3850000.000000000000000,5850000.000000000000000)
> Pixel Size = (25000.000000000000000,-25000.000000000000000)
> Metadata:
>   AREA_OR_POINT=Area
> Image Structure Metadata:
>   INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  (-3850000.000, 5850000.000)
> Lower Left  (-3850000.000,-5350000.000)
> Upper Right ( 3750000.000, 5850000.000)
> Lower Right ( 3750000.000,-5350000.000)
> Center      (  -50000.000,  250000.000)
> Band 1 Block=304x26 Type=Byte, ColorInterp=Gray
>   NoData Value=255
>
> Here is the gdalinfo output from the geoTiff obtained from a WCS
> GetCoverage request from geoserver v2.10.3:
>
> Driver: GTiff/GeoTIFF
> Files: /home/trst2284/Downloads/NSIDC-TEST_MOSAIC.tif
> Size is 296, 360
> Coordinate System is:
> LOCAL_CS["unnamed",
>     GEOGCS["unknown",
>         DATUM["unknown",
>             SPHEROID["unretrievable - using
> WGS84",6378137,298.257223563]],
>         PRIMEM["Greenwich",0],
>         UNIT[,0.0174532925199433]],
>     AUTHORITY["EPSG","3411"],
>     UNIT["unknown",1]]
> Origin = (-3650000.000000000000000,3650000.000000000000000)
> Pixel Size = (25000.000000000000000,-25000.000000000000000)
> Metadata:
>   AREA_OR_POINT=Area
>   TIFFTAG_RESOLUTIONUNIT=1 (unitless)
>   TIFFTAG_XRESOLUTION=1
>   TIFFTAG_YRESOLUTION=1
> Image Structure Metadata:
>   INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  (-3650000.000, 3650000.000)
> Lower Left  (-3650000.000,-5350000.000)
> Upper Right ( 3750000.000, 3650000.000)
> Lower Right ( 3750000.000,-5350000.000)
> Center      (   50000.000, -850000.000)
> Band 1 Block=304x368 Type=Byte, ColorInterp=Gray
>   NoData Value=0
>
>
> Any suggestions on how I might resolve this problem would be
> appreciated! I have not come across any bug reports that seem to have
> this same problem, but I'll be happy to submit one if this ends up
> being a bug.
>
> Thanks!
>
> Trey Stafford
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

wrong.png (4K) Download Attachment
correct.png (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Offset/wrong bounding box

geowolf
The short version of the answer is "I have no clue" :-)
Wondering:
  • Could you try 2.11.1 or 2.10.4 (just released)
  • If the issue can be reproduced there too, can you share a sample dataset and request to reproduce the problem?
Cheers
Andrea


On Thu, Jun 22, 2017 at 1:01 AM, Trey Stafford <[hidden email]> wrote:
All,

I appear to have attached the wrong example images (the previous ones were from a separate issue which seems to be resolved with v2.10.3). You will find the correct images attached to this reply.

My apologies for any confusion this may have caused!

Thanks again,

Trey



On 06/21/2017 04:28 PM, Trey Stafford wrote:
Hello,

I have recently attempted upgrading my version of GeoServer from v2.10.1 (Ubuntu Linux 16.04.2 LTS) to v2.11.1. Although the upgrade went smoothly, I am now observing an offset in the bounding box Geoserver appears to be using for my image layers. I have tested this problem on versions 2.10.2, 2.10.3, and 2.11.1. The problem appears in versions after 2.10.2.

My layers are configured to use EPSG 3411 (NSIDC Sea Ice Polar Stereographic North), and I have confirmed that the projection definition remains the same between the versions that I have tested.

My problem is apparent with a simple WMS request to get the full layer, using its configured bounds. When requested using v2.10.1, the image looks as expected (see correct.png, attached). When requested using versions after 2.10.2, geoserver seems to get these bounds wrong (see incorrect.png). I also see this problem when I request the image as a GeoTIFF using a WCS GetCoverage request. The GeoTiff downloaded via WCS is correctly referenced (I can pull it into QGIS just fine), but still only contains the 'offset' parts from the original image.

I observe this offset problem with both image mosaics and single image GeoTiff stores.

gdalinfo output for the image featured in the attached images is below:

Driver: GTiff/GeoTIFF
Files: 20170620_N_20170620_extent_v2.1.tif
Size is 304, 448
Coordinate System is:
LOCAL_CS["NSIDC Sea Ice Polar Stereographic North",
    GEOGCS["Unspecified datum based upon the Hughes 1980 ellipsoid",
        DATUM["unknown",
            SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    AUTHORITY["EPSG","3411"],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (-3850000.000000000000000,5850000.000000000000000)
Pixel Size = (25000.000000000000000,-25000.000000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-3850000.000, 5850000.000)
Lower Left  (-3850000.000,-5350000.000)
Upper Right ( 3750000.000, 5850000.000)
Lower Right ( 3750000.000,-5350000.000)
Center      (  -50000.000,  250000.000)
Band 1 Block=304x26 Type=Byte, ColorInterp=Gray
  NoData Value=255

Here is the gdalinfo output from the geoTiff obtained from a WCS GetCoverage request from geoserver v2.10.3:

Driver: GTiff/GeoTIFF
Files: /home/trst2284/Downloads/NSIDC-TEST_MOSAIC.tif
Size is 296, 360
Coordinate System is:
LOCAL_CS["unnamed",
    GEOGCS["unknown",
        DATUM["unknown",
            SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT[,0.0174532925199433]],
    AUTHORITY["EPSG","3411"],
    UNIT["unknown",1]]
Origin = (-3650000.000000000000000,3650000.000000000000000)
Pixel Size = (25000.000000000000000,-25000.000000000000000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_RESOLUTIONUNIT=1 (unitless)
  TIFFTAG_XRESOLUTION=1
  TIFFTAG_YRESOLUTION=1
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-3650000.000, 3650000.000)
Lower Left  (-3650000.000,-5350000.000)
Upper Right ( 3750000.000, 3650000.000)
Lower Right ( 3750000.000,-5350000.000)
Center      (   50000.000, -850000.000)
Band 1 Block=304x368 Type=Byte, ColorInterp=Gray
  NoData Value=0


Any suggestions on how I might resolve this problem would be appreciated! I have not come across any bug reports that seem to have this same problem, but I'll be happy to submit one if this ends up being a bug.

Thanks!

Trey Stafford



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users




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

Ing. Andrea Aime 
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549


AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Offset/wrong bounding box

Trey Stafford

Andrea,

I have now tried using both version 2.11.1 and 2.10.4: both have the described offset problem.

This issue can be easily reproduced by taking the following steps:

1. Download the GeoTiff file at this location: ftp://sidads.colorado.edu/DATASETS/NOAA/G02135/north/monthly/geotiff/05_May/N_201705_extent_v2.1.tif
2. Create and publish a GeoTIFF store using the above file.
3. Use the 'layer preview' menu to, for example, download a png image. In versions after 2.10.2 the offset will be observed.

I appreciate your response - hopefully this helps!

Trey


On 06/22/2017 01:39 AM, Andrea Aime wrote:
The short version of the answer is "I have no clue" :-)
Wondering:
  • Could you try 2.11.1 or 2.10.4 (just released)
  • If the issue can be reproduced there too, can you share a sample dataset and request to reproduce the problem?
Cheers
Andrea


On Thu, Jun 22, 2017 at 1:01 AM, Trey Stafford <[hidden email]> wrote:
All,

I appear to have attached the wrong example images (the previous ones were from a separate issue which seems to be resolved with v2.10.3). You will find the correct images attached to this reply.

My apologies for any confusion this may have caused!

Thanks again,

Trey



On 06/21/2017 04:28 PM, Trey Stafford wrote:
Hello,

I have recently attempted upgrading my version of GeoServer from v2.10.1 (Ubuntu Linux 16.04.2 LTS) to v2.11.1. Although the upgrade went smoothly, I am now observing an offset in the bounding box Geoserver appears to be using for my image layers. I have tested this problem on versions 2.10.2, 2.10.3, and 2.11.1. The problem appears in versions after 2.10.2.

My layers are configured to use EPSG 3411 (NSIDC Sea Ice Polar Stereographic North), and I have confirmed that the projection definition remains the same between the versions that I have tested.

My problem is apparent with a simple WMS request to get the full layer, using its configured bounds. When requested using v2.10.1, the image looks as expected (see correct.png, attached). When requested using versions after 2.10.2, geoserver seems to get these bounds wrong (see incorrect.png). I also see this problem when I request the image as a GeoTIFF using a WCS GetCoverage request. The GeoTiff downloaded via WCS is correctly referenced (I can pull it into QGIS just fine), but still only contains the 'offset' parts from the original image.

I observe this offset problem with both image mosaics and single image GeoTiff stores.

gdalinfo output for the image featured in the attached images is below:

Driver: GTiff/GeoTIFF
Files: 20170620_N_20170620_extent_v2.1.tif
Size is 304, 448
Coordinate System is:
LOCAL_CS["NSIDC Sea Ice Polar Stereographic North",
    GEOGCS["Unspecified datum based upon the Hughes 1980 ellipsoid",
        DATUM["unknown",
            SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    AUTHORITY["EPSG","3411"],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (-3850000.000000000000000,5850000.000000000000000)
Pixel Size = (25000.000000000000000,-25000.000000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-3850000.000, 5850000.000)
Lower Left  (-3850000.000,-5350000.000)
Upper Right ( 3750000.000, 5850000.000)
Lower Right ( 3750000.000,-5350000.000)
Center      (  -50000.000,  250000.000)
Band 1 Block=304x26 Type=Byte, ColorInterp=Gray
  NoData Value=255

Here is the gdalinfo output from the geoTiff obtained from a WCS GetCoverage request from geoserver v2.10.3:

Driver: GTiff/GeoTIFF
Files: /home/trst2284/Downloads/NSIDC-TEST_MOSAIC.tif
Size is 296, 360
Coordinate System is:
LOCAL_CS["unnamed",
    GEOGCS["unknown",
        DATUM["unknown",
            SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT[,0.0174532925199433]],
    AUTHORITY["EPSG","3411"],
    UNIT["unknown",1]]
Origin = (-3650000.000000000000000,3650000.000000000000000)
Pixel Size = (25000.000000000000000,-25000.000000000000000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_RESOLUTIONUNIT=1 (unitless)
  TIFFTAG_XRESOLUTION=1
  TIFFTAG_YRESOLUTION=1
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-3650000.000, 3650000.000)
Lower Left  (-3650000.000,-5350000.000)
Upper Right ( 3750000.000, 3650000.000)
Lower Right ( 3750000.000,-5350000.000)
Center      (   50000.000, -850000.000)
Band 1 Block=304x368 Type=Byte, ColorInterp=Gray
  NoData Value=0


Any suggestions on how I might resolve this problem would be appreciated! I have not come across any bug reports that seem to have this same problem, but I'll be happy to submit one if this ends up being a bug.

Thanks!

Trey Stafford



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users




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

Ing. Andrea Aime 
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549


AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Reply | Threaded
Open this post in threaded view
|

Re: Offset/wrong bounding box

Trey Stafford

It appears that GEOS-8542 (https://osgeo-org.atlassian.net/browse/GEOS-8542) resolves this issue. Thanks, Andrea!


On 06/22/2017 09:15 AM, Trey Stafford wrote:

Andrea,

I have now tried using both version 2.11.1 and 2.10.4: both have the described offset problem.

This issue can be easily reproduced by taking the following steps:

1. Download the GeoTiff file at this location: ftp://sidads.colorado.edu/DATASETS/NOAA/G02135/north/monthly/geotiff/05_May/N_201705_extent_v2.1.tif
2. Create and publish a GeoTIFF store using the above file.
3. Use the 'layer preview' menu to, for example, download a png image. In versions after 2.10.2 the offset will be observed.

I appreciate your response - hopefully this helps!

Trey


On 06/22/2017 01:39 AM, Andrea Aime wrote:
The short version of the answer is "I have no clue" :-)
Wondering:
  • Could you try 2.11.1 or 2.10.4 (just released)
  • If the issue can be reproduced there too, can you share a sample dataset and request to reproduce the problem?
Cheers
Andrea


On Thu, Jun 22, 2017 at 1:01 AM, Trey Stafford <[hidden email]> wrote:
All,

I appear to have attached the wrong example images (the previous ones were from a separate issue which seems to be resolved with v2.10.3). You will find the correct images attached to this reply.

My apologies for any confusion this may have caused!

Thanks again,

Trey



On 06/21/2017 04:28 PM, Trey Stafford wrote:
Hello,

I have recently attempted upgrading my version of GeoServer from v2.10.1 (Ubuntu Linux 16.04.2 LTS) to v2.11.1. Although the upgrade went smoothly, I am now observing an offset in the bounding box Geoserver appears to be using for my image layers. I have tested this problem on versions 2.10.2, 2.10.3, and 2.11.1. The problem appears in versions after 2.10.2.

My layers are configured to use EPSG 3411 (NSIDC Sea Ice Polar Stereographic North), and I have confirmed that the projection definition remains the same between the versions that I have tested.

My problem is apparent with a simple WMS request to get the full layer, using its configured bounds. When requested using v2.10.1, the image looks as expected (see correct.png, attached). When requested using versions after 2.10.2, geoserver seems to get these bounds wrong (see incorrect.png). I also see this problem when I request the image as a GeoTIFF using a WCS GetCoverage request. The GeoTiff downloaded via WCS is correctly referenced (I can pull it into QGIS just fine), but still only contains the 'offset' parts from the original image.

I observe this offset problem with both image mosaics and single image GeoTiff stores.

gdalinfo output for the image featured in the attached images is below:

Driver: GTiff/GeoTIFF
Files: 20170620_N_20170620_extent_v2.1.tif
Size is 304, 448
Coordinate System is:
LOCAL_CS["NSIDC Sea Ice Polar Stereographic North",
    GEOGCS["Unspecified datum based upon the Hughes 1980 ellipsoid",
        DATUM["unknown",
            SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    AUTHORITY["EPSG","3411"],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (-3850000.000000000000000,5850000.000000000000000)
Pixel Size = (25000.000000000000000,-25000.000000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-3850000.000, 5850000.000)
Lower Left  (-3850000.000,-5350000.000)
Upper Right ( 3750000.000, 5850000.000)
Lower Right ( 3750000.000,-5350000.000)
Center      (  -50000.000,  250000.000)
Band 1 Block=304x26 Type=Byte, ColorInterp=Gray
  NoData Value=255

Here is the gdalinfo output from the geoTiff obtained from a WCS GetCoverage request from geoserver v2.10.3:

Driver: GTiff/GeoTIFF
Files: /home/trst2284/Downloads/NSIDC-TEST_MOSAIC.tif
Size is 296, 360
Coordinate System is:
LOCAL_CS["unnamed",
    GEOGCS["unknown",
        DATUM["unknown",
            SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT[,0.0174532925199433]],
    AUTHORITY["EPSG","3411"],
    UNIT["unknown",1]]
Origin = (-3650000.000000000000000,3650000.000000000000000)
Pixel Size = (25000.000000000000000,-25000.000000000000000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_RESOLUTIONUNIT=1 (unitless)
  TIFFTAG_XRESOLUTION=1
  TIFFTAG_YRESOLUTION=1
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-3650000.000, 3650000.000)
Lower Left  (-3650000.000,-5350000.000)
Upper Right ( 3750000.000, 3650000.000)
Lower Right ( 3750000.000,-5350000.000)
Center      (   50000.000, -850000.000)
Band 1 Block=304x368 Type=Byte, ColorInterp=Gray
  NoData Value=0


Any suggestions on how I might resolve this problem would be appreciated! I have not come across any bug reports that seem to have this same problem, but I'll be happy to submit one if this ends up being a bug.

Thanks!

Trey Stafford



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users




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

Ing. Andrea Aime 
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549


AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

 

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


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



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:
- Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users