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

[David Chandler]

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 Aime]

Post by David Chandler
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: [phone]
fax: [phone]
mob: [phone]

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

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

[David Chandler]

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

Post by David Chandler
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: [phone]
fax: [phone]
mob: [phone]
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------

[Andrea Aime]

Post by David Chandler
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.

Post by David Chandler
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: [phone]
fax: [phone]
mob: [phone]

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

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

[David Chandler]

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

Post by David Chandler
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: [phone]
fax: [phone]
mob: [phone]
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------

[Andrea Aime]

Post by David Chandler
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:

[image: Inline image 1]

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

[image: Inline image 2]

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: [phone]
fax: [phone]
mob: [phone]

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

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

[David Chandler]

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
<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
<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

On Thu, Nov 28, 2013 at 12:56 PM, David Chandler
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
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 Aime]

Post by David Chandler
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: [phone]
fax: [phone]
mob: [phone]

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

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

[David Chandler]

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

Post by David Chandler
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: [phone]
fax: [phone]
mob: [phone]
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------

[Andrea Aime]

Post by David Chandler
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

Post by David Chandler
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: [phone]
fax: [phone]
mob: [phone]

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

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