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
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-
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
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
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
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
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
>
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
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,
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
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
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
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
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
14 matches
Mail list logo