[Geoserver-users] 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

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.
Driver: GTiff/GeoTIFF
Files: 20170620_N_20170620_extent_v2.1.tif
Size is 304, 448
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)
AREA_OR_POINT=Area
INTERLEAVE=BAND
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
Driver: GTiff/GeoTIFF
Files: /home/trst2284/Downloads/NSIDC-TEST_MOSAIC.tif
Size is 296, 360
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)
AREA_OR_POINT=Area
TIFFTAG_RESOLUTIONUNIT=1 (unitless)
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
INTERLEAVE=BAND
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

[Andrea Aime]

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

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

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.
Driver: GTiff/GeoTIFF
Files: 20170620_N_20170620_extent_v2.1.tif
Size is 304, 448
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)
AREA_OR_POINT=Area
INTERLEAVE=BAND
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
Driver: GTiff/GeoTIFF
Files: /home/trst2284/Downloads/NSIDC-TEST_MOSAIC.tif
Size is 296, 360
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)
AREA_OR_POINT=Area
TIFFTAG_RESOLUTIONUNIT=1 (unitless)
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
INTERLEAVE=BAND
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
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: [phone]
fax: [phone]
mob: [phone]

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

*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.

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

[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

Post by Andrea Aime
The short version of the answer is "I have no clue" :-)
* 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
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
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.
Driver: GTiff/GeoTIFF
Files: 20170620_N_20170620_extent_v2.1.tif
Size is 304, 448
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)
AREA_OR_POINT=Area
INTERLEAVE=BAND
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
Driver: GTiff/GeoTIFF
Files: /home/trst2284/Downloads/NSIDC-TEST_MOSAIC.tif
Size is 296, 360
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)
AREA_OR_POINT=Area
TIFFTAG_RESOLUTIONUNIT=1 (unitless)
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
INTERLEAVE=BAND
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
https://lists.sourceforge.net/lists/listinfo/geoserver-users
<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: [phone]
fax: [phone]
mob: [phone]
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
*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.
-------------------------------------------------------