Hi Paul,
I've turned your mail into a ticket here:
https://osgeo-org.atlassian.net/browse/GEOS-7976
Cheers
Andrea
On Wed, Feb 1, 2017 at 4:23 PM, Paul Madden <[email protected]> wrote:
> Hi Jukka,
>
>
> Here are steps to reproduce:
>
>
> 1. Download and unpack geoserver-2.10.x-latest-bin.zip (Feb 1, 2017).
> 2. Start the server: java -jar start.jar.
> 3. Log in and create default workspace "ws".
> 4. Turn on verbose logging and log to stdout.
> 5. Download and unpack test data: https://www.dropbox.com/
> s/6tk2k7oz6icoxjf/icetest.zip?dl=0
> 6. Create GeoTIFF store "ice" using 20120101_sea_ice_cover_ice.tif.
> 7. Publish layer with default name:
> - SRS handling: Keep native (Is this the best choice?)
> - Native Bounding Box: Compute from data
> - Lat/Lon Bounding Box: Compute from native bounds
> - Coverage Band Details: Null Values = -999, minRange = 20, maxRange =
> 40
>
> This native-projection WMS request works fine:
>
> http://localhost:8080/geoserver/ws/wms?service=WMS&;
> version=1.1.0&request=GetMap&layers=ws:20120101_sea_ice_
> cover_ice&styles=&bbox=-5000000,-5000000,5000000,
> 5000000&width=100&height=100&srs=EPSG:6931&format=image/png
>
> This reprojection to EPSG:3413 is slow, but succeeds:
>
> http://localhost:8080/geoserver/ws/wms?service=WMS&;
> version=1.1.0&request=GetMap&layers=ws:20120101_sea_ice_
> cover_ice&styles=&bbox=-5000000,-5000000,5000000,
> 5000000&width=100&height=100&srs=EPSG:3413&format=image/png
>
> This request, where only the image size changes, spikes the CPU for some
> time, then fails with the log info included in the test-data zipfile, and
> returns to my browser the file called "wms" in the zipfile:
>
> http://localhost:8080/geoserver/ws/wms?service=WMS&;
> version=1.1.0&request=GetMap&layers=ws:20120101_sea_ice_
> cover_ice&styles=&bbox=-5000000,-5000000,5000000,
> 5000000&width=800&height=800&srs=EPSG:3413&format=image/png
>
> It seems that this may be RAM-sensitive, so you may need to use larger
> image sizes to see an error if you have more memory. If you keep increasing
> the image size, I suspect you will run into the same error.
>
> I also included in the zipfile the original NetCDF file from which the
> GeoTIFF was created, in case there is some obvious problem with this. I
> used the command:
>
> gdal_translate -a_srs EPSG:6931
> NETCDF:asicd25e2_20120101_v01r02.nc:sea_ice_cover
> 20120101_sea_ice_cover_ice.tif
>
> paul
>
>
> ------------------------------
> *From:* Rahkonen Jukka (MML) <[email protected]>
> *Sent:* Wednesday, February 1, 2017 00:59
>
> *To:* Paul Madden; [email protected]
> *Subject:* Re: [Geoserver-users] Dimensions "are too large" when
> requesting reprojected raster via WMS
>
>
> Hi,
>
>
> I guess that your issue happens in some specific case and therefore it can
> be hard to catch by others. It would be excellent if you could prepere a
> re-producible test set with an image and advice about how to make a layer
> from it, and WMS requests to test with.
>
>
> -Jukka Rahkonen-
> ------------------------------
> Paul Madden wrote:
> Re: [Geoserver-users] Dimensions "are too large" when requesting
> reprojected raster via WMS
>
>
> I am still surprised that simply changing the size of the requested image
> leads to an error, but I have given up -- for now -- on trying to
> understand exactly why. As long as I avoid requesting certain bbox values,
> it seems that I can avoid errors, and that will have to be good enough for
> now. I will try investigating the developer-level logs if I run into the
> issue again.
>
>
> For what it's worth, I can open one of my GeoTIFF files in QGIS, view it
> in the native EPSG:6931 projection (which I have to define as a Custom CRS,
> as it is apparently unknown to QGIS, and also reproject it to EPSG:3413 and
> even mix with with layers requested from a remote GeoServer whose native
> projection is EPSG:3413.
>
> I have a new problem, with ImageMosaic, but will start a new thread to ask
> about that if I cannot find a solution in the list archive.
>
> thanks,
> paul
>
> ------------------------------
> *From:* Rahkonen Jukka (MML) <[email protected]>
> *Sent:* Tuesday, January 24, 2017 02:07
> *To:* Paul Madden; [email protected]
> *Subject:* Re: [Geoserver-users] Dimensions "are too large" when
> requesting reprojected raster via WMS
>
>
> Hi,
>
>
> Sorry for reading too many zeros from your GetMap requests.
>
> For why EPSG:6931 GetMap works with extra large BBOX I believe it is
> because EPSG:6931 is the native projection of your data. There is no need
> to reproject the bounding box and map gets filled with empty pixels where
> there are no image data. If the bounding box must be re-projected first
> then unreasonable big coordinate values can lead to an error because the
> transformation formula may not be able to handle it. Sometimes is happens,
> sometimes not, and it depends on the transformation library and source and
> target SRS.
>
>
> So, probably I was wrong with my thoughts about too large coordinate
> values. However, what I wrote about BBOX coordinates which need to be
> expressed in the same units than SRS is right.
>
>
> I can't say why you get the errror by just increasing height and width.
> Turn the logging level of your Geoserver into Geotools developer and have a
> look what you get into log. Have you tried if your map works with QGIS in
> both projections?
>
>
> -Jukka Rahkonen-
>
>
>
>
> ------------------------------
> *Lähettäjä:* Paul Madden <[email protected]>
> *Lähetetty:* 24. tammikuuta 2017 7:52
> *Vastaanottaja:* Rahkonen Jukka (MML); geoserver-users@lists.
> sourceforge.net
> *Aihe:* Re: [Geoserver-users] Dimensions "are too large" when requesting
> reprojected raster via WMS
>
>
> 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
>
>
--
==
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
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.
-------------------------------------------------------
------------------------------------------------------------------------------
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
