[Geoserver-users] weird rendering when specifiyng buffer parameter on layergroups containing raster data layers

David_Chandler · November 25, 2013, 2:17pm

hi,
I’m working actually with Geoserver 2.4.1 (java 1.6.0_26/ native JAI and JAI ImageIO installed)

I have a layergroup made by mixed vectors data types and raster data types.
I need to specifying buffer in my own,( buffer is different on each zoom level because SLD contains sizes specified as feature attribute values, in uom= “meter”).
when I add a buffer parameter in my getmap option -for example buffer of 250 pix for a width/height image of 500 pix-
rasters data resolution are reduced by 2 in my image. the more the ratio bufferLength/widthImageLength is high, the more the final rendering of raster layer is low.
Is this a normal behavior?
I can imagine that for that kind of layer (raster data), buffer param should be desactivated in any circumtances…
thanks
DChandler

illustrative examples

fig 1: width/heigt :current bounding box 512 pix with buffer not specified (0), raster layer (grey shades) is ok

fig 2: width/heigt :current bounding box 512 pix with buffer=256 pix, raster resolution is bad

fig 3: width/heigt :current bounding box 512 pix with buffer=2560 pix, raster resolution is very bad

Andrea_Aime4 · November 27, 2013, 10:44am

On Mon, Nov 25, 2013 at 3:17 PM, David Chandler <david.chandler@anonymised.com>wrote:

hi,
I'm working actually with Geoserver 2.4.1 (java 1.6.0_26/ native JAI and
JAI ImageIO installed)

I have a layergroup made by mixed vectors data types and raster data types.
I need to specifying buffer in my own,( buffer is different on each zoom
level because SLD contains sizes specified as feature attribute values, in
uom= "meter").
when I add a buffer parameter in my getmap option -for example buffer of
250 pix for a width/height image of 500 pix-
rasters data resolution are reduced by 2 in my image. the more the ratio
bufferLength/widthImageLength is high, the more the final rendering of
raster layer is low.
Is this a normal behavior?
I can imagine that for that kind of layer (raster data), buffer param
should be desactivated in any circumtances...
thanks
DChandler

illustrative examples

fig 1: width/heigt :current bounding box 512 pix with buffer not specified
(0), raster layer (grey shades) is ok

fig 2: width/heigt :current bounding box 512 pix with buffer=256 pix,
raster resolution is bad

fig 3: width/heigt :current bounding box 512 pix with buffer=2560 pix,
raster resolution is very bad

Hi David,
yes, this looks like a bug happening when a list of layers involving a
raster is painted, and the buffer
parameter is used.

I'm working on that area of code just today for another reason, should not
be too hard to fix.

Just out of curiosity, is the buffer=2560px just set to make the resolution
problem more evident,
or do you have a real need for it?

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

David_Chandler · November 27, 2013, 3:03pm

Hi Andrea,
Thanks for your response.
Yes, the 2560 pix. with a little current bounding boxing was to illustrate. But we do not know which size we will need, could be large.
Actually, we investigate how to avoid desactivation of labels when the text overlaps two tiles. For our use case, we would prefer to truncate these texts at tiles border in order to draw each text part on separate tiles.
This has been discussed in the past (http://osgeo-org.1560.x6.nabble.com/Labels-disappear-when-extended-over-several-tiles-td5067295.html )
Maybe we will propose a modification soon. Our tests with buffer size are related to this topic.
Regards

DChandler

Le 27/11/2013 11:44, Andrea Aime a écrit :

On Mon, Nov 25, 2013 at 3:17 PM, David Chandler <david.chandler@anonymised.com. <mailto:david.chandler@anonymised.com>> wrote:

    hi,
    I'm working actually with Geoserver 2.4.1 (java 1.6.0_26/ native
    JAI and JAI ImageIO installed)

    I have a layergroup made by mixed vectors data types and raster
    data types.
    I need to specifying buffer in my own,( buffer is different on
    each zoom level because SLD contains sizes specified as feature
    attribute values, in uom= "meter").
    when I add a buffer parameter in my getmap option -for example
    buffer of 250 pix for a width/height image of 500 pix-
     rasters data resolution are reduced by 2 in my image. the more
    the ratio bufferLength/widthImageLength is high, the more the
    final rendering of raster layer is low.
    Is this a normal behavior?
    I can imagine that for that kind of layer (raster data), buffer
    param should be desactivated in any circumtances...
    thanks
    DChandler

    illustrative examples

    fig 1: width/heigt :current bounding box 512 pix with buffer not
    specified (0), raster layer (grey shades) is ok

    fig 2: width/heigt :current bounding box 512 pix with buffer=256
    pix, raster resolution is bad

    fig 3: width/heigt :current bounding box 512 pix with buffer=2560
    pix, raster resolution is very bad

Hi David,
yes, this looks like a bug happening when a list of layers involving a raster is painted, and the buffer
parameter is used.

I'm working on that area of code just today for another reason, should not be too hard to fix.

Just out of curiosity, is the buffer=2560px just set to make the resolution problem more evident,
or do you have a real need for it?

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Andrea_Aime4 · November 28, 2013, 9:54am

On Wed, Nov 27, 2013 at 4:03 PM, David Chandler <david.chandler@anonymised.com>wrote:

Hi Andrea,
Thanks for your response.
Yes, the 2560 pix. with a little current bounding boxing was to
illustrate. But we do not know which size we will need, could be large.

Can you try out the "latest" build here?
http://ares.boundlessgeo.com/geoserver/master/

It should contain a fix for the issue you reported.

Actually, we investigate how to avoid desactivation of labels when the
text overlaps two tiles. For our use case, we would prefer to truncate
these texts at tiles border in order to draw each text part on separate
tiles.
This has been discussed in the past (
http://osgeo-org.1560.x6.nabble.com/Labels-disappear-when-extended-over-several-tiles-td5067295.html)
Maybe we will propose a modification soon. Our tests with buffer size are
related to this topic.

I see. With conflict resolution enabled there is no way to ensure the label
will be also painted in the next tile,
but if you have sparse high priority labels, or disable conflict
resolution, it may work (that is, you should be
able to get the other half of the label painted in the nearby tile).

The vendor option to disable conflict resolution exists already, we'd need
one to allow "partials".
When this is enabled, other changes should be probably made, like for
example avoid clipping polygons before
extracting the label points, and so on.

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

David_Chandler · November 28, 2013, 11:56am

Hi,
I downloaded the last build (28-Nov-2013 08:13),
but it seems to be the same as before (bad resolution with large or very large buffer for raster data )
regards
DChandler

Le 28/11/2013 10:54, Andrea Aime a écrit :

On Wed, Nov 27, 2013 at 4:03 PM, David Chandler <david.chandler@anonymised.com. <mailto:david.chandler@anonymised.com>> wrote:

    Hi Andrea,
    Thanks for your response.
    Yes, the 2560 pix. with a little current bounding boxing was to
    illustrate. But we do not know which size we will need, could be
    large.

Can you try out the "latest" build here?
http://ares.boundlessgeo.com/geoserver/master/

It should contain a fix for the issue you reported.

    Actually, we investigate how to avoid desactivation of labels when
    the text overlaps two tiles. For our use case, we would prefer to
    truncate these texts at tiles border in order to draw each text
    part on separate tiles.
    This has been discussed in the past
    (http://osgeo-org.1560.x6.nabble.com/Labels-disappear-when-extended-over-several-tiles-td5067295.html
    )
    Maybe we will propose a modification soon. Our tests with buffer
    size are related to this topic.

I see. With conflict resolution enabled there is no way to ensure the label will be also painted in the next tile,
but if you have sparse high priority labels, or disable conflict resolution, it may work (that is, you should be
able to get the other half of the label painted in the nearby tile).

The vendor option to disable conflict resolution exists already, we'd need one to allow "partials".
When this is enabled, other changes should be probably made, like for example avoid clipping polygons before
extracting the label points, and so on.

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Andrea_Aime4 · December 1, 2013, 10:15am

On Thu, Nov 28, 2013 at 12:56 PM, David Chandler <david.chandler@anonymised.com>wrote:

Hi,
I downloaded the last build (28-Nov-2013 08:13),
but it seems to be the same as before (bad resolution with large or very
large buffer for raster data )

I've just made some tests of my own, and wondering if you are looking at
cached results, or if we
are doing the tests in a different way.

Here is a request the stock "spearfish" layer, which as a raster in it,
with buffer = 1024:

http://localhost:8080/geoserver/wms?LAYERS=spearfish&STYLES=&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A26713&BBOX=593134.45711644,4916462.8550766,603180.82597618,4923507.086367&WIDTH=512&HEIGHT=359&buffer=1024

And here is the result for November 27 nightly (one day before the patch),
raster
pixelation is pretty evident in the areas where orange turns to yellow:

!spearfish-1128.jpg|512x359

and with the November 28 nightly, where the full resolutions is being used
instead:

!spearfish-1127.jpg|512x359

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

David_Chandler · December 2, 2013, 8:14am

Hi Andrea,
I re-installed the 28 nov build :

and made the same request on "spearfish" as you in your in precedent mail:

1) with a 0 (or unspecified) buffer
http://localhost:8080/geoserver/wms?LAYERS=spearfish&STYLES=&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A26713&BBOX=593134.45711644,4916462.8550766,603180.82597618,4923507.086367&WIDTH=512&HEIGHT=359&buffer=1024>&buffer=0 <http://localhost:8080/geoserver/wms?LAYERS=spearfish&STYLES=&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A26713&BBOX=593134.45711644,4916462.8550766,603180.82597618,4923507.086367&WIDTH=512&HEIGHT=359&buffer=1024>

3)with a 2048 buffer
http://localhost:8080/geoserver/wms?LAYERS=spearfish&STYLES=&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A26713&BBOX=593134.45711644,4916462.8550766,603180.82597618,4923507.086367&WIDTH=512&HEIGHT=359&buffer=1024>&buffer=2048 <http://localhost:8080/geoserver/wms?LAYERS=spearfish&STYLES=&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A26713&BBOX=593134.45711644,4916462.8550766,603180.82597618,4923507.086367&WIDTH=512&HEIGHT=359&buffer=1024>

pixelation is always visible in 3)

I also tried with the last build (01-Dec-2013 ), I have the same behavior...

maybe I missed something ?
regards,

DChandler

Le 01/12/2013 11:15, Andrea Aime a écrit :

On Thu, Nov 28, 2013 at 12:56 PM, David Chandler <david.chandler@anonymised.com <mailto:david.chandler@anonymised.com>> wrote:

    Hi,
    I downloaded the last build (28-Nov-2013 08:13),
    but it seems to be the same as before (bad resolution with large
    or very large buffer for raster data )

I've just made some tests of my own, and wondering if you are looking at cached results, or if we
are doing the tests in a different way.

Here is a request the stock "spearfish" layer, which as a raster in it, with buffer = 1024:

http://localhost:8080/geoserver/wms?LAYERS=spearfish&STYLES=&FORMAT=image%2Fjpeg&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A26713&BBOX=593134.45711644,4916462.8550766,603180.82597618,4923507.086367&WIDTH=512&HEIGHT=359&buffer=1024

And here is the result for November 27 nightly (one day before the patch), raster
pixelation is pretty evident in the areas where orange turns to yellow:-------------------------------------------------------

Andrea_Aime4 · December 6, 2013, 9:55am

On Mon, Dec 2, 2013 at 9:14 AM, David Chandler <david.chandler@anonymised.com>wrote:

I also tried with the last build (01-Dec-2013 ), I have the same
behavior...

maybe I missed something ?

Hmm... no idea. To make sure, today I had a Dec 6th build from 2.4.x
installed locally, and repeated
the tests from another browser (just to make sure there are no caching
effects) and I cannot
reproduce the problem anymore...

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

David_Chandler · December 6, 2013, 3:20pm

Hi Andrea,
I just try with the last build (geoserver-master-2013-12-06-war)
and now it's working perfectly ( no more pixelation and raster data with big buffer).
pehaps an explanation why the 28 nov and the 1 december .war were not working : in these, the gt-render-11-SNAPSHOT.jar was build the 2013-11-26 (so before the bug fix ...) ...
anyway, thank for this fix!
Regards
DChandler

Le 06/12/2013 10:55, Andrea Aime a écrit :

On Mon, Dec 2, 2013 at 9:14 AM, David Chandler <david.chandler@anonymised.com <mailto:david.chandler@anonymised.com>> wrote:

    I also tried with the last build (01-Dec-2013 ), I have the same
    behavior...

    maybe I missed something ?

Hmm... no idea. To make sure, today I had a Dec 6th build from 2.4.x installed locally, and repeated
the tests from another browser (just to make sure there are no caching effects) and I cannot
reproduce the problem anymore...

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Andrea_Aime4 · December 6, 2013, 3:26pm

On Fri, Dec 6, 2013 at 4:20 PM, David Chandler <david.chandler@anonymised.com>wrote:

Hi Andrea,
I just try with the last build (geoserver-master-2013-12-06-war)
and now it's working perfectly ( no more pixelation and raster data with
big buffer).
pehaps an explanation why the 28 nov and the 1 december .war were not
working : in these, the gt-render-11-SNAPSHOT.jar was build the 2013-11-26
(so before the bug fix ...) ...

Ah... I guess I had another GeoServer running on port 8080 when I tried the
28 build then, and did not notice

anyway, thank for this fix!

No problem

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------