Re: [Geoserver-devel] DynamicColorMap

Hmm, I think the issue is in that area though: I changed this: MathTransform g2w = reader.getOriginalGridToWorld(PixelInCell.CELL_CENTER); to this: MathTransform g2w = reader.getOriginalGridToWorld(PixelInCell.CELL_CORNER); (full diff here: https://github.com/dvntucker/geotools/pull/6/files)

Re: [Geoserver-devel] [gdal-dev] GML lat-lon coverages and interoperability

On 04/05/2017 02:16 PM, Andrea Aime wrote: > On Tue, Apr 4, 2017 at 12:24 PM, Peter Baumann > wrote: > > To avoid the problems that other standards have with axis order, coverages > contain the axis order

Re: [Geoserver-devel] DynamicColorMap

I don't use the dynamic colormap module but the JIRA ticket in the first post has a test case using it: https://osgeo-org.atlassian.net/browse/GEOS-8070 Adding 1 to the envelope width and height here seems to fix the problem:

Re: [Geoserver-devel] DynamicColorMap

You could start by providing a reproducable test case in Jira :-) Cheers Andrea On Wed, Apr 5, 2017 at 4:40 PM, sikeoka wrote: > I've also seen issues with GeoServer potentially losing the right-most and > bottom-most pixels when using rendering transformations to style

Re: [Geoserver-devel] WPS S3 Artifact Plugin

Cool, le us know if you get stuck waiting on some actions from our side. Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito

Re: [Geoserver-devel] DynamicColorMap

I've also seen issues with GeoServer potentially losing the right-most and bottom-most pixels when using rendering transformations to style raster data. I've reproduced this in 2.9.x and 2.10.x with GeoTIFF coverages and with raster-to-raster and raster-to-vector transformations. This can create

Re: [Geoserver-devel] DynamicColorMap

Either I have forgotten or it was somebody else... can't find it back. Interesting about that other issue btw, that should resolve it indeed On 05-04-17 14:18, Andrea Aime wrote: Nope, not that one. You did find some issues with code removing 1 from the pixel grid extents, if memory serves me

Re: [Geoserver-devel] DynamicColorMap

Nope, not that one. You did find some issues with code removing 1 from the pixel grid extents, if memory serves me right. Btw that issue you are pointing to might have been solved recently by avoiding the large raster space coordinates in image mosaic:

Re: [Geoserver-devel] [gdal-dev] GML lat-lon coverages and interoperability

On Tue, Apr 4, 2017 at 12:24 PM, Peter Baumann < p.baum...@jacobs-university.de> wrote: > To avoid the problems that other standards have with axis order, coverages > contain the axis order explicitly, in the axisLabels attribute. Here an > example: > >

Re: [Geoserver-devel] DynamicColorMap

You mean this https://osgeo-org.atlassian.net/browse/GEOS-7793 ? On 05-04-17 12:57, Andrea Aime wrote: Hi Devon, short answer is... I have no clue. Yes, indeed the path between RT and non RT cannot be the same, one works off a reader, the other off a coverage and the RT can influence what is

Re: [Geoserver-devel] DynamicColorMap

Hi Devon, short answer is... I have no clue. Yes, indeed the path between RT and non RT cannot be the same, one works off a reader, the other off a coverage and the RT can influence what is being read (area and resolution). I would not blame the geometry per se though, some time ago Niels was

[Geoserver-devel] [JIRA] (GEOS-8073) Performing a WMTS GetCapabilities request with layer groups provokes a NPE

Title: Message Title Nuno Oliveira