Thanks Steve, you're right, just changing the cell anchor does not fix it.

I'm actually a decent bit confused by this bug at this point. I think it
may be related to cropping the coverage after the read? The rendering
transform pipeline increases the size of the bounding box to ensure that at
least one pixel is returned, then in the very next step the coverage is
cropped to the exact same envelope in case the coverage store returns more
than the requested bounds. This is where things go wrong, because the bbox
of the coverage that returns ends up being smaller than the one requested
for the crop. I put the coverage + the bboxes into QGIS to see what's going
on:

http://imgur.com/a/xxR81

Apologies for the awful image, I'll try to explain it:

- The background is the water temp raster from the ticket.
- the "inner" bbox with the black diamond outline is the requested bbox
from the WMS request.
- the biggest, outermost bbox with the blue squares outline is the expanded
bbox done by the Rendering transform code. So far so good. See
https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/lite/RenderingTransformationHelper.java#L121
- the smaller leftmost bbox with the red circle outline is the coverage
bbox AFTER the rendering transformation helper does a crop using the
expanded bbox. I think this is where things go wrong. The intersection of
this bbox and the requested bbox explains the resuling image (see the
second image in that link)

So, I think something is going wrong in that crop operating (
https://github.com/geotools/geotools/blob/master/modules/library/render/src/main/java/org/geotools/renderer/lite/RenderingTransformationHelper.java#L152).
The BBOX handed in to the crop is the biggest expanded one, but for
whatever reason the resulting coverage has the smaller bbox. Not quite sure
what's going on there. I'm continuing to look at it today.

Cheers

On Thu, Apr 6, 2017 at 2:47 PM, sikeoka <[email protected]> wrote:

> I downloaded the 10.47 MB GeoTIFF from here and loaded it into GeoServer:
> http://www.naturalearthdata.com/downloads/50m-raster-data/50m-gray-earth/
>
> I created a new style called contour_test (full SLD at the end).  I then
> used the following URLs against a GeoServer that is patched with the
> CELL_CORNER fix.  All three URLs work fine when adding 1 to the width and
> height and all three have significant gaps without either fix.  I tested
> against GeoServer 2.10.1 using native JAI.
>
> works fine:
> http://localhost:8080/geoserver/wms?service=WMS&;
> version=1.3.0&request=GetMap&format=image/png&crs=CRS:84&
> layers=gis:GRAY_50M_SR_W&styles=contour_test&bgcolor=
> 0xFF0000&width=800&height=800&bbox=71.0,35.0,71.08,35.08
>
> has missing contours on the right side of the image:
> http://localhost:8080/geoserver/wms?service=WMS&;
> version=1.3.0&request=GetMap&format=image/png&crs=CRS:84&
> layers=gis:GRAY_50M_SR_W&styles=contour_test&bgcolor=
> 0xFF0000&width=800&height=800&bbox=71.0,35.0,71.09,35.09
>
> works fine:
> http://localhost:8080/geoserver/wms?service=WMS&;
> version=1.3.0&request=GetMap&format=image/png&crs=CRS:84&
> layers=gis:GRAY_50M_SR_W&styles=contour_test&bgcolor=
> 0xFF0000&width=800&height=800&bbox=71.0,35.0,71.1,35.1
>
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <StyledLayerDescriptor version="1.0.0" xmlns="http://www.opengis.net/sld";
> xmlns:ogc="http://www.opengis.net/ogc";
>   xmlns:xlink="http://www.w3.org/1999/xlink";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://www.opengis.net/sld
> http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd";>
>     <NamedLayer>
>         <Name>contour_test</Name>
>         <LayerFeatureConstraints>
>             <FeatureTypeConstraint/>
>         </LayerFeatureConstraints>
>         <UserStyle>
>             <FeatureTypeStyle>
>                 <Transformation>
>                     <ogc:Function name="ras:Contour">
>                         <ogc:Function name="parameter">
>                             <ogc:Literal>data</ogc:Literal>
>                         </ogc:Function>
>                         <ogc:Function name="parameter">
>                             <ogc:Literal>interval</ogc:Literal>
>                             <ogc:Literal>5</ogc:Literal>
>                         </ogc:Function>
>                     </ogc:Function>
>                 </Transformation>
>                 <Rule>
>                     <LineSymbolizer>
>                         <Stroke>
>                             <CssParameter
> name="stroke">#000000</CssParameter>
>                         </Stroke>
>                     </LineSymbolizer>
>                 </Rule>
>             </FeatureTypeStyle>
>         </UserStyle>
>     </NamedLayer>
> </StyledLayerDescriptor>
>
> Steve Ikeoka
>
>
>
> --
> View this message in context: http://osgeo-org.1560.x6.
> nabble.com/DynamicColorMap-tp5315555p5316209.html
> Sent from the GeoServer - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to