Winbarbs after GEOT-7690

Hi,

first of all, after having migrated to 2.27.x we have been experiencing a dramatic increase of performance of the raster-to-point processes. Thanks everyone who was involved into making that important improvement! :clap: :clap:

But there is one thing now that we cannot quite figure ourselves. With the changes to [GEOT-7690] Fixes and improvements for contour/windbard rendering by aaime · Pull Request #5009 · geotools/geotools · GitHub we are now having trouble aligning our windbarbs to look nicely on tiled maps.

We have numerical weather prediction data of wind-speed and direction combined in a coverage view. In both version (2.23.6 and now 2.27.1) we are using the following CSS for that layer:

@styleTitle 'Wind barbs (m/s)';
@styleAbstract 'Wind barbs (m/s)';

* {
  
  /* transform the raster into points */
  transform: 
    ras:RasterAsPointCollection(
      emisphere : true, scale : 0.015);
  
  /* wind barbs symbol from wind speed */
  mark: symbol('windbarbs://default(${wind_speed})[m/s]?emisphere=${emisphere}');
  
  /* symbol rotation from wind direction and size from wind-speed */
  :nth-mark(1) {
	rotation: [wind_direction];
  	size: [categorize(wind_speed, 4, 1.543, 20)];
   	stroke: red;
   	label-obstacle: true;
  };
  
  /* prevent symbol overlapping */
  mark-label-obstacle: true;
}

Note, that the data has a resolution of 0.0625 degrees in lat/lon, which is why we require that very small scaling factor of 0.015.

With 2.23.6 the data looked like that on an EPSG:3857 map display:

Note, that we have a 256x256 tile-size (displayed as black rectangles). Interestingly now with 2.27.1 it looks like this:

The problem that we are having is that for the old version you can see that the distances of sampled points looks pretty equidistant with respect to the overall display. Now with 2.27.1 the display looks a bit more consistent when looking at an individual tile, but now the overall display on the maps is not pleasant anymore. The distance of marks across tile boundaries smaller than the distance of points within a tile.

As far as I understand the changes that were made, the idea was to clip the image precisely at the rendering envelope, because otherwise labels/marks/barbs could be cut off. I think over all that change makes sense, but is there any way that could help restoring the equidistant look and feel across tile boundaries?

Thanks!

Now that I am looking further, what astonishes me is that even though my tiles are 256x256, after clipping the cropped coverage still has en envelope of [[-10..265], [-11..266]]. That’s not what I had expected, assuming I understood the intention of clipping correctly.

Then when that coverage is passed to the RasterAsPointCollectionProcess it comes in with that envelope and coverageWitdth=276 and coverageHeight=278.

Shouldn’t they be rather 256,256? Note sure though if that makes a big difference, because the width/height isn’t considered for the scaling anyway.

Btw, on EPSG:4336, it doesn’t look all that bad:

  • scale factor: 0.2
  • black: GS 2.23.6
  • red: GS 2.27.1

Even the windbarbs look as if they are not cut off, as they seem to be picked up by the neighbouring tile for continue rendering the missing part

Still the same data visualized on EPSG:3857 looks pretty bad:

  • scale factor: 0.03
  • black: GS 2.23.6
  • red: GS 2.27.1

In both version symbols are cut and not continued on the next tile, and the distance between “rows” / “columns” of symbols are not equal in 2.27.1:

Hi skalesse

I don’t have any knowledge or opinion on the majority of your question, sorry, but regarding the image size, is it possible that tiles have a margin (gutter) of 10px?

10 + 256 + 10 = 276

Peter

@Peter ,

yes they do seem to have a gutter. But why? There’s not a single where that gutter would have been specified.

Here’s an example request that we are sending:

http://localhost/geoserver/ows?REQUEST=GetMap&
SERVICE=WMS&
VERSION=1.3.0&
FORMAT=image/png&
STYLES=modeldata:NWP.WindBarbs_speedDir&
TRANSPARENT=TRUE&
LAYERS=modeldata:Icon_reg025_fd_pl_WIND&
tiled=true&
TIME=2025-06-24T13:00:00.000Z&
ELEVATION=1000&
DIM_REFERENCE_TIME=2025-06-24T06:00:00.000Z&
WIDTH=256&
HEIGHT=256&
CRS=EPSG:3857&
BBOX=-626172.1357121654,6261721.357121639,-1.5133991837501526e-9,6887893.4928338025

That request will generate a tile as this:

and these are the settings for that layer:

and we are not using GWC at all. So I cannot think of anything that would add that buffer there. :thinking: