Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Andrea Aime
On Fri, Aug 11, 2017 at 11:32 AM, Rahkonen Jukka (MML) < jukka.rahko...@maanmittauslaitos.fi> wrote: > Hi, > > > > I would have a try with SCALESIZE and SCALEEXTENT parameters of the > scaling extension https://portal.opengeospatial.org/files/12-039. In > theory GetCoverage should keep the

Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Rahkonen Jukka (MML)
Hi, I would have a try with SCALESIZE and SCALEEXTENT parameters of the scaling extension https://portal.opengeospatial.org/files/12-039. In theory GetCoverage should keep the native pixel size but it may be that GeoServer does not really know what the native pixel size is. -Jukka Rahkonen-

[Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Anna-Lena.Hock
Hello everyone, we recently tested the WCS of Geoserver. We want to use the service to request images in different projections. Our data source is in UTM32N and we requested GK3 images with coordinates in GK3. Here is the request: {_URL_}wcs?SERVICE=WCS=2.0.1=GetCoverage=raster_test:DTK100n

Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Rahkonen Jukka (MML)
Hi, The native pixel size in UTM32N is obviously 5.00 m. UTM projection is using a scale factor of 0.9996 and if you convert a polygon of size 5x5 m (presenting one pixel) into EPSG:31467 it will grow into 5.0020008x5.0020008 meters. That process is converting each pixel as they are without

Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Anna-Lena.Hock
Hello Andrea, yes, I did. But I send it again: I requested in GK3: SUBSET=Y,http://www.opengis.net/def/crs/EPSG/0/31467(340,342)=X,http://www.opengis.net/def/crs/EPSG/0/31467(566,568) AND set the crs to be the same: =http://www.opengis.net/def/crs/EPSG/0/31467

Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Rahkonen Jukka (MML)
I have been reading again and again this: “fill this new image extent with pixel values re-projected from the coverage’s Native CRS to the output CRS in a way that, for each axis, the smallest distance between any two reprojected grid points is used as offset” I do believe now that “the

Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Andrea Aime
On Fri, Aug 11, 2017 at 1:45 PM, wrote: > As far as I can interpret this, it means that in case we have OUTPUTCRS > equals SUBSETTINGCRS the extent of the image should be exactly the one > requested in SUBSET. The request coordinates aren’t transformed – the >

Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Rahkonen Jukka (MML)
Hi, I did not notice that reprojection happens. I had a look at the CRS extension standard. First thing that it says is that range set values should not change without CRS change. “The GetCoverage request is extended with two optional parameters indicating the CRSs for subsetting coordinates

Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Andrea Aime
On Fri, Aug 11, 2017 at 12:21 PM, Rahkonen Jukka (MML) < jukka.rahko...@maanmittauslaitos.fi> wrote: > Hi, > > > > I did not notice that reprojection happens. > Ah sorry, I thought you did not when I read you stating that the server should keep the native resolution... which, when reprojecting,

Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Rahkonen Jukka (MML)
Hi, I am not a programmer but I can imagine that a bounding box that is expressed in non-native projection is first re-projected into the native CRS which means that it gets rotated and resized. Then some image data are clipped by the envelope of the rotated BBOX and re-projected into the

Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Anna-Lena.Hock
As far as I can interpret this, it means that in case we have OUTPUTCRS equals SUBSETTINGCRS the extent of the image should be exactly the one requested in SUBSET. The request coordinates aren’t transformed – the bounding box is “fixed” and the image is filled in this extent. If you vary the

Re: [Geoserver-users] Limit to Number of Feature Chained Elements?

2017-08-11 Thread Ben Caradoc-Davies
Gavin, every source feature has its own connection pool. Use the same JNDI source for all source features to have them use a single pool that you can make as large as you like. The new functionality is in 2.11.2 and master so you should have it. Kind regards, Ben. On 12/08/17 06:37, Gavin

Re: [Geoserver-users] Limit to Number of Feature Chained Elements?

2017-08-11 Thread Gavin Medley
Hi Ben, How does App Schema use the connections pool? Does it create a new connection for each mapping file? I am running 2.11.2. Is the new development in the nightly build? On Thu, Aug 10, 2017 at 5:29 PM, Ben Caradoc-Davies wrote: > Gavin, > > there is no limit in

Re: [Geoserver-users] WCS returns wrong GeoTiffs

2017-08-11 Thread Andrea Aime
Hi Jukka, thanks for the explanation. I would like to add one more bit about the meaning of the target bbox: the output coverage must be contained in it, but it does not have to match it. This is by specification, although it's not so clear to read: "The result coverage shall contain only those