Hi Jukka,
Many thanks for your response, it was helpful and gave me more to think about.
> 30, 50, or 70 million meters is much more than 2.3 million meters and 382
> thousand meters which are valid for eastings and northings in EPSG:3413,
> respectively.
My bounds were actually 3, 5 and 7 million meters (hopefully I did not make a
typo in my previous post) rather than 30, 50 and 70 -- though this does not
contradict your point that these values lie outside valid EPSG:3413
coordinates. However, I notice that my OpenLayers application regularly
generates bbox values outside EPSG:3413's range, which GeoServer seems to have
no trouble with. In fact, I just tried an EPSG:3413 WMS request with a *70*
million meter square bbox, against a native-SRS EPSG:3413 layer, and GeoServer
returned a correct-looking image.
When I try your gdaltransform example with 3, 5 and 7 million meter values, I
see no more NANs (though I am not sure what to make of the values that are
returned).
> You say that the EPSG:6931 coordinates are ok.
I am not sure that they are ok (i.e. valid), but GeoServer seems to handle them
gracefully -- as long as I do not request reprojection. I just tried EPSG:6931
WMS requests with both 7 and 70 million meter square bboxes, against the native
EPSG:6931 layer, and GeoServer returned images for both requests.
A colleague told me today that some coordinates, in meters, when interpreted
with respect to EPSG:6931, cannot be mapped to lat/lon points. So I wonder
whether it might be the case that, when reprojecting between SRSes, an
intermediate projection to lat/lon is performed, so that NAN values appear for
non-reprojectable EPSG:6931 coordinates, aborting the process. But, somehow,
GeoServer copes with e.g. a 70 million meter square bbox when reprojection is
NOT requested, perhaps by reducing it to the bounds known/declared to be valid
for the layer.
Here is another strange (to me) case that I'm still confused about. This
request returns a correct-looking image:
<https://localhost:8080/geoserver/NSIDC/wms?service=WMS&version=1.1.0&request=GetMap&layers=NSIDC:nsidc_0532_sea_ice_cover&styles=&bbox=-5000000,-5000000,5000000,5000000&width=500&height=500&srs=EPSG:3413&format=image/png>https://localhost:8080/geoserver/NSIDC/wms?service=WMS&version=1.1.0&request=GetMap&layers=NSIDC:nsidc_0532_sea_ice_cover&styles=&bbox=-5000000,-5000000,5000000,5000000&width=500&height=500&srs=EPSG:3413&format=image/png<https://qa.bedims-geoserver-standalone.apps.int.nsidc.org/geoserver/NSIDC/wms?service=WMS&version=1.1.0&request=GetMap&layers=NSIDC:nsidc_0532_sea_ice_cover&styles=&bbox=-5000000,-5000000,5000000,5000000&width=500&height=500&srs=EPSG:3413&format=image/png>
But this request
https://localhost:8080/geoserver/NSIDC/wms?service=WMS&version=1.1.0&request=GetMap&layers=NSIDC:nsidc_0532_sea_ice_cover&styles=&bbox=-5000000,-5000000,5000000,5000000&width=800&height=800&srs=EPSG:3413&format=image/png
returns the same XML "Dimensions (width=59142 height=59142) are too large"
error mentioned in my previous post. The only difference is the width & height
of the requested image, not the bbox, or the fact that a reprojection to
EPSG:3413 is requested from the native EPSG:6931.
I'd like to have a better mental model of what is happening here. Am I simply
in undefined-behavior territory, by using too-large bbox values, sometimes
getting lucky and sometimes not? The fact that I can succeed or fail based on
the image size makes it seem a bit like a resource issue. Also, I'm surprised
that I can use a too-big bbox when I do not request reprojection, but I cannot
(or sometimes cannot) when I do request reprojection. The latter is probably
naiveté on my part.
Again, I would appreciate any insight on this.
paul
________________________________
From: Rahkonen Jukka (MML) <[email protected]>
Sent: Monday, January 23, 2017 08:46
To: Paul Madden; [email protected]
Subject: Re: [Geoserver-users] Dimensions "are too large" when requesting
reprojected raster via WMS
Hi,
The BBOX and SRS (which actually shoud be CRC when you use WMS 1.3.0) go hand
in hand. If you want to achieve a map from the same area you can’t just change
the projection but you must use also BBOX that is re-projected to the other
coordinate system. WMS clients like QGIS or OpenJUMP do it automatically.
I had a try with a gdaltransform utility http://www.gdal.org/gdaltransform.html
and tried to convert the lower-left corners of your EPSG:6931 BBOXes into
EPSG:3413. The result was that two of those (-50000000 -50000000 and -30000000
-30000000) gives “not a number” which means that conversion is not possible.
gdaltransform -s_srs epsg:6931 -t_srs epsg:3413
-50000000 -50000000
1.#QNAN 1.#QNAN 0
-7000000 -7000000
3.37694958262492e-009 -15208428.8819585 0
-30000000 -30000000
1.#QNAN 1.#QNAN 0
I do not know why transformation fails. You say that the EPSG:6931 coordinates
are ok.
However, by having a look at projection EPSG:3413 https://epsg.io/3413 it is
obvious that your hand written bounding boxes do not make sense because the
coordinates do not fit inside the valid area of that coordinate system:
Projected bounds:
-2353926.81 2345724.36
-382558.89 383896.60
30, 50, or 70 million meters is much more than 2.3 million meters and 382
thousand meters which are valid for eastings and northings in EPSG:3413,
respectively.
What you need to do is simple to use EPSG:3413 bounding box with CRS:3413.
-Jukka Rahkonen-
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
