[Geoserver-users] Antarctic Polar Stereographic Coverage [Sec=Unclassified]

GeoServer GeoServer User
1

Hi,

I’m experiencing a similar problem mentioned in the following post:
http://www.nabble.com/antarctic-polar-stereographic-coverage-td19666877.html

Basically, using coverages defined in EPSG:3031 Antarctic Polar Stereographic are failing to load.

As far as I knew, this issue was fixed (I discussed the issue with the original poster) - I downloaded a nightly build just after this thread was posted and it worked. However, I’ve since upgraded and the issue is back, and have no idea which exact date it was that the working nightly build came from.

I’ve tried a few things and various different geotiffs from different sources, checked them all with gdalinfo and they all seem fine… Here’s what happens:

Trying to create a CoverageStore with a geotiff without having tiled it with gdal_translate produces an onscreen Exception with a one line warning in the log:
13 Mar 11:23:03 WARN [org.apache.struts.action.RequestProcessor] - Unhandled Exception thrown: class java.lang.IllegalArgumentException

http://data.aad.gov.au/temp/miles/geoserver_onscreen.txt

Trying to create a CoverageStore with a geotiff that has been tiled and/or has overviews added seems to create fine, but then when the coverage editor comes up it puts UNKNOWN in the SRS. Manually putting in EPSG:3031 in the CRS, Request SRS and Response SRS fields and hitting submit doesn’t seem to produce any error. However a basic getMap request come up blank, with the old “This AxisDirection object is too complex for WKT syntax” exception (http://data.aad.gov.au/temp/miles/geoserver.log) which I’ve been told before can be ignored.

Also, i noticed that the gdalinfo output for the tiled file: http://data.aad.gov.au/temp/miles/gdalinfo.txt
is different to the Native SRS WKT shown on the coverage editor screen: http://data.aad.gov.au/temp/miles/guessed_native_srs.txt

The one I am using is variant B of EPSG:3031 with the -71 latitude of origin, which is the same as geoserver shows in the SRS list for 3031 and the definition more widely accepted by the antarctic community. Somehow the native SRS that comes up for the coverage when it’s loaded is similar to the old variant of EPSG:3031, with a latitude of origin of -90, only the scale factor is wrong in that case.

So I guess what has got me wondering now is that if the WKT gdalinfo shows about my geotiff and the WKT that is in the Geoserver SRS List are the same, how is it coming up with something else?

I apologise for the long post - just trying to be thorough. The above is applicable to clean war installs of the 12-March Nightly Build and Stable 1.7.3, among other, older versions I’ve tested.

Regards,

Miles Jordan
Applications Developer
Australian Antarctic Division
[P] +61 3 6232 3486

Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not the
intended recipient, you are notified that use or dissemination of this communication is
strictly prohibited by Commonwealth law. If you have received this transmission in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/

2

Miles Jordan ha scritto:

Hi, <http://www.nabble.com/antarctic-polar-stereographic-coverage-td19666877.html&gt;
I'm experiencing a similar problem mentioned in the following post:
http://www.nabble.com/antarctic-polar-stereographic-coverage-td19666877.html
Basically, using coverages defined in EPSG:3031 Antarctic Polar Stereographic are failing to load.
As far as I knew, this issue was fixed (I discussed the issue with the original poster) - I downloaded a nightly build just after this thread was posted and it worked. However, I've since upgraded and the issue is back, and have no idea which exact date it was that the working nightly build came from.

Bad. We need at least to know which version that was. Was it a 1.6.4?
Also the thread on Nabble does not mention any actual fix, so if anything happened, it was by private mail?

I've tried a few things and various different geotiffs from different sources, checked them all with gdalinfo and they all seem fine... Here's what happens:
Trying to create a CoverageStore with a geotiff without having tiled it with gdal_translate produces an onscreen Exception with a one line warning in the log:
13 Mar 11:23:03 WARN [org.apache.struts.action.RequestProcessor] - Unhandled Exception thrown: class java.lang.IllegalArgumentException
http://data.aad.gov.au/temp/miles/geoserver_onscreen.txt

This error is thrown when a GeneralEnvelope is built so that the
xmin > xmax or ymin > ymax. I guess the odd axis order might be
confusing the code that reads the envelope?

Trying to create a CoverageStore with a geotiff that has been tiled and/or has overviews added seems to create fine, but then when the coverage editor comes up it puts UNKNOWN in the SRS. Manually putting in EPSG:3031 in the CRS, Request SRS and Response SRS fields and hitting submit doesn't seem to produce any error. However a basic getMap request come up blank, with the old "This AxisDirection object is too complex for WKT syntax" exception (http://data.aad.gov.au/temp/miles/geoserver.log) which I've been told before can be ignored.
Also, i noticed that the gdalinfo output for the tiled file: http://data.aad.gov.au/temp/miles/gdalinfo.txt
is different to the Native SRS WKT shown on the coverage editor screen: http://data.aad.gov.au/temp/miles/guessed_native_srs.txt The one I am using is variant B of EPSG:3031 with the -71 latitude of origin, which is the same as geoserver shows in the SRS list for 3031 and the definition more widely accepted by the antarctic community. Somehow the native SRS that comes up for the coverage when it's loaded is similar to the old variant of EPSG:3031, with a latitude of origin of -90, only the scale factor is wrong in that case.

GeoServer is using an old EPSG database, the referencing subsystem maintainer in GeoTools (the library we use for referencing services)
hasn't been updating it in a long time.
But anyways, you can define you own version of 3031 an override the one
coming from the epsg database by adding a "epsg_overrides.properties"
file in the data directory, $datadir/user_projections/epsg_overrides.properties, pasting
3001=your_wkt_definition_in_a_single_line
pretty much following the lead of the epsg.properties file
(which on the contrary adds new codes, but does not override official
ones).

So I guess what has got me wondering now is that if the WKT gdalinfo shows about my geotiff and the WKT that is in the Geoserver SRS List are the same, how is it coming up with something else?
I apologise for the long post - just trying to be thorough. The above is applicable to clean war installs of the 12-March Nightly Build and Stable 1.7.3, among other, older versions I've tested.

If the above does not help, can you provide us with a sample coverage
to test against?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

3

I'm having the same problem as described in this thread.
Trying to add a GeoTiff in antarctic polar stereographic to geoserver and it
fails with a
    * class java.lang.IllegalArgumentException: Bad ordinates at dimension
0.

Details:

java.lang.IllegalArgumentException: Bad ordinates at dimension 0.
  at
org.geotools.geometry.GeneralEnvelope.checkCoordinates(GeneralEnvelope.java:335)
  at org.geotools.geometry.GeneralEnvelope.(GeneralEnvelope.java:133)
  at org.geotools.geometry.GeneralEnvelope.(GeneralEnvelope.java:153)
  at org.geotools.referencing.CRS.transform(CRS.java:1137)

I'm running Geoserver 1.7.5 on Ubuntu 8.10.
I tried the suggested method, creating an epsg_overrides.properties, but
that doesn't seem to help.

Any news on this issue?

Cheers,
Niels

Andrea Aime-4 wrote:

Miles Jordan ha scritto:

Hi,
<http://www.nabble.com/antarctic-polar-stereographic-coverage-td19666877.html&gt;

I'm experiencing a similar problem mentioned in the following post:
http://www.nabble.com/antarctic-polar-stereographic-coverage-td19666877.html

Basically, using coverages defined in EPSG:3031 Antarctic Polar
Stereographic are failing to load.

As far as I knew, this issue was fixed (I discussed the issue with the
original poster) - I downloaded a nightly build just after this thread
was posted and it worked. However, I've since upgraded and the issue is
back, and have no idea which exact date it was that the working nightly
build came from.

Bad. We need at least to know which version that was. Was it a 1.6.4?
Also the thread on Nabble does not mention any actual fix, so if
anything happened, it was by private mail?

I've tried a few things and various different geotiffs from different
sources, checked them all with gdalinfo and they all seem fine... Here's
what happens:

Trying to create a CoverageStore with a geotiff without having tiled it
with gdal_translate produces an onscreen Exception with a one line
warning in the log:
13 Mar 11:23:03 WARN [org.apache.struts.action.RequestProcessor] -
Unhandled Exception thrown: class java.lang.IllegalArgumentException
http://data.aad.gov.au/temp/miles/geoserver_onscreen.txt

This error is thrown when a GeneralEnvelope is built so that the
xmin > xmax or ymin > ymax. I guess the odd axis order might be
confusing the code that reads the envelope?

Trying to create a CoverageStore with a geotiff that has been tiled
and/or has overviews added seems to create fine, but then when the
coverage editor comes up it puts UNKNOWN in the SRS. Manually putting in
EPSG:3031 in the CRS, Request SRS and Response SRS fields and hitting
submit doesn't seem to produce any error. However a basic getMap request
come up blank, with the old "This AxisDirection object is too complex
for WKT syntax" exception
(http://data.aad.gov.au/temp/miles/geoserver.log) which I've been told
before can be ignored.

Also, i noticed that the gdalinfo output for the tiled file:
http://data.aad.gov.au/temp/miles/gdalinfo.txt
is different to the Native SRS WKT shown on the coverage editor screen:
http://data.aad.gov.au/temp/miles/guessed_native_srs.txt
The one I am using is variant B of EPSG:3031 with the -71 latitude of
origin, which is the same as geoserver shows in the SRS list for 3031
and the definition more widely accepted by the antarctic community.
Somehow the native SRS that comes up for the coverage when it's loaded
is similar to the old variant of EPSG:3031, with a latitude of origin of
-90, only the scale factor is wrong in that case.

GeoServer is using an old EPSG database, the referencing subsystem
maintainer in GeoTools (the library we use for referencing services)
hasn't been updating it in a long time.
But anyways, you can define you own version of 3031 an override the one
coming from the epsg database by adding a "epsg_overrides.properties"
file in the data directory,
$datadir/user_projections/epsg_overrides.properties, pasting
3001=your_wkt_definition_in_a_single_line
pretty much following the lead of the epsg.properties file
(which on the contrary adds new codes, but does not override official
ones).

So I guess what has got me wondering now is that if the WKT gdalinfo
shows about my geotiff and the WKT that is in the Geoserver SRS List are
the same, how is it coming up with something else?

I apologise for the long post - just trying to be thorough. The above is
applicable to clean war installs of the 12-March Nightly Build and
Stable 1.7.3, among other, older versions I've tested.

If the above does not help, can you provide us with a sample coverage
to test against?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://www.nabble.com/Antarctic-Polar-Stereographic-Coverage--Sec%3DUnclassified--tp22489193p24472993.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

4

As Andrea stated the easiest way for us to diagnose the problem would be to reproduce it with some of your data, or any data that produces the problem. Any chance you can send one of us a portion of your geotiff via private email?

Niels Hoffmann wrote:

I'm having the same problem as described in this thread.
Trying to add a GeoTiff in antarctic polar stereographic to geoserver and it
fails with a
    * class java.lang.IllegalArgumentException: Bad ordinates at dimension
0.

Details:

java.lang.IllegalArgumentException: Bad ordinates at dimension 0.
  at
org.geotools.geometry.GeneralEnvelope.checkCoordinates(GeneralEnvelope.java:335)
  at org.geotools.geometry.GeneralEnvelope.(GeneralEnvelope.java:133)
  at org.geotools.geometry.GeneralEnvelope.(GeneralEnvelope.java:153)
  at org.geotools.referencing.CRS.transform(CRS.java:1137)

I'm running Geoserver 1.7.5 on Ubuntu 8.10.
I tried the suggested method, creating an epsg_overrides.properties, but
that doesn't seem to help.

Any news on this issue?

Cheers,
Niels

Andrea Aime-4 wrote:

Miles Jordan ha scritto:

Hi, <http://www.nabble.com/antarctic-polar-stereographic-coverage-td19666877.html&gt;
I'm experiencing a similar problem mentioned in the following post:
http://www.nabble.com/antarctic-polar-stereographic-coverage-td19666877.html
Basically, using coverages defined in EPSG:3031 Antarctic Polar Stereographic are failing to load.
As far as I knew, this issue was fixed (I discussed the issue with the original poster) - I downloaded a nightly build just after this thread was posted and it worked. However, I've since upgraded and the issue is back, and have no idea which exact date it was that the working nightly build came from.

Bad. We need at least to know which version that was. Was it a 1.6.4?
Also the thread on Nabble does not mention any actual fix, so if anything happened, it was by private mail?

I've tried a few things and various different geotiffs from different sources, checked them all with gdalinfo and they all seem fine... Here's what happens:
Trying to create a CoverageStore with a geotiff without having tiled it with gdal_translate produces an onscreen Exception with a one line warning in the log:
13 Mar 11:23:03 WARN [org.apache.struts.action.RequestProcessor] - Unhandled Exception thrown: class java.lang.IllegalArgumentException
http://data.aad.gov.au/temp/miles/geoserver_onscreen.txt

This error is thrown when a GeneralEnvelope is built so that the
xmin > xmax or ymin > ymax. I guess the odd axis order might be
confusing the code that reads the envelope?

Trying to create a CoverageStore with a geotiff that has been tiled and/or has overviews added seems to create fine, but then when the coverage editor comes up it puts UNKNOWN in the SRS. Manually putting in EPSG:3031 in the CRS, Request SRS and Response SRS fields and hitting submit doesn't seem to produce any error. However a basic getMap request come up blank, with the old "This AxisDirection object is too complex for WKT syntax" exception (http://data.aad.gov.au/temp/miles/geoserver.log) which I've been told before can be ignored.
Also, i noticed that the gdalinfo output for the tiled file: http://data.aad.gov.au/temp/miles/gdalinfo.txt
is different to the Native SRS WKT shown on the coverage editor screen: http://data.aad.gov.au/temp/miles/guessed_native_srs.txt The one I am using is variant B of EPSG:3031 with the -71 latitude of origin, which is the same as geoserver shows in the SRS list for 3031 and the definition more widely accepted by the antarctic community. Somehow the native SRS that comes up for the coverage when it's loaded is similar to the old variant of EPSG:3031, with a latitude of origin of -90, only the scale factor is wrong in that case.

GeoServer is using an old EPSG database, the referencing subsystem maintainer in GeoTools (the library we use for referencing services)
hasn't been updating it in a long time.
But anyways, you can define you own version of 3031 an override the one
coming from the epsg database by adding a "epsg_overrides.properties"
file in the data directory, $datadir/user_projections/epsg_overrides.properties, pasting
3001=your_wkt_definition_in_a_single_line
pretty much following the lead of the epsg.properties file
(which on the contrary adds new codes, but does not override official
ones).

So I guess what has got me wondering now is that if the WKT gdalinfo shows about my geotiff and the WKT that is in the Geoserver SRS List are the same, how is it coming up with something else?
I apologise for the long post - just trying to be thorough. The above is applicable to clean war installs of the 12-March Nightly Build and Stable 1.7.3, among other, older versions I've tested.

If the above does not help, can you provide us with a sample coverage
to test against?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

Hello,

The problem described in this thread is one we at British Antarctic Survey
have come across repeatedly in Geoserver versions up to and including 1.7.3.
The latest 2.0 seems to exhibit a different problem which might be merely
because the original error is trapped and the report comes from higher up in
the stack.

Basically we create a coverage store from the image using Geoserver web
interface, and then are unable to add a coverage - the error is always as
described earlier in this thread.

It would be a help to us to know whether or not this problem is being worked
on at the moment. We have put together a data case (available via anonymous
ftp at ftp://ftp.bas.ac.uk/ancz, file b.tif) of one of our Geotiffs (68Mb)
which we hope will be of help in fixing the problem.

Thanks very much,

David Herbert
British Antarctic Survey.

Justin Deoliveira-6 wrote:

As Andrea stated the easiest way for us to diagnose the problem would be
to reproduce it with some of your data, or any data that produces the
problem. Any chance you can send one of us a portion of your geotiff via
private email?

--
View this message in context: http://old.nabble.com/Antarctic-Polar-Stereographic-Coverage--Sec%3DUnclassified--tp22489193p26635837.html
Sent from the GeoServer - User mailing list archive at Nabble.com.