2

I have a streams layer that renders with a label.

I've noticed that the label renders differently if I use a WMS GetMap request, vs. if I use a GeoWebCache (GWC) request.

Here is an example:

This is a WMS GetMap request result:

WMS GetMap request

This is a GWC request result:

GeoWebCache (GWC) request

Notice how the Merced River label is positioned differently the two images?

These are both the same layer, using the same style.

This is very weird. I'd think that they'd render the same, regardless of if it's already been cached. It's a problem for my workflow, which combines WMS with GWC and relies on the labels rendering in the same place.


@Son of a Beach asked why I need to render using both GWC and WMS. GWC is so much faster if they tiles are pre-baked. However, we want to be able to select a stream by clicking on it, and have it be in a "selected" state, i.e. render with a different style. So I just have a second layer on the map, e.g. streams_selected, which includes a filter with its WMS Get Map request. The filter is for a particular feature ID. It renders on top of the GWC (unselected) layer. I need the labels to line up so it doesn't look funky.

  • 4
    Your GWC service is cached and pre-rendered. The labeling in this service was at a tile level. For example: In your GWC example you can see two labels for "Merced River". Most likely that duplicate label exists because of the tile scene configuration. Each label could represent a unique tile. The WMS is labeling features dynamically versus is being pre-rendered. The extent of your view probably does not match up with the extent used to create tiles in the GWC service and I suspect that is why you are seeing a discrepancy in labeling. – Scobert Feb 16 '17 at 21:59
  • 1
    Labeling happens rather at metatile level geowebcache.org/docs/current/concepts/metatiles.html. – user30184 Feb 16 '17 at 22:06
  • 1
    If you were able to match the extent of your WMS with the extent used to pre-render each "Metatile" you might be able to match up the labels. – Scobert Feb 16 '17 at 22:17
4

The WMS image is rendered based on the BBOX (extent) for the entire image request. The labeling rules apply to the extent of the WMS image request.

The GWC images are each rendered for either each individual tile, or for each metatile, depending on your configuration. Either way, the extent is different to that for which the WMS image is rendered.

For example, the system will usually avoid having labels that intersect the boundary of the image (so that labels do not get truncated at the image boundary). In the case of WMS, this means the boundary of the requested extent. In the case of tiles, this means all of the boundaries of every tile/metatile.

Therefore any label that was on (or near) a tile/metatile boundary, will be moved elsewhere in the GWC rendering, but will not be moved in the WMS version (except where that is also the WMS request extent boundary).

I reckon that there is a vertical tile boundary somewhere in the shaded part of this image (below). WMS doesn't have tile boundaries here, so the labels can intersect this part of the image. GWC does have this tile boundary, and so tries to avoid placing labels there.

enter image description here

You can tell Geoserver to render labels across boundaries using <VendorOption name="partials">true</VendorOption> (and then you'd have to re-seed your GWC cache), however, the labels would still not be garanteed to be in the same position as in WMS, due to other variables. Eg, the optimal position for a label may be "as far away from all other labels as possible", and this would be different for a small tile than it would be for a larger WMS render.

I think the real solution to this issue is likely to require using WMTS or TMS instead of WMS, or some other mechanism by which you render the image using the same tile grid as the GWC cached tiles.

If this does not help, could you please update your question to explain why you need to use both WMS and GWC? Understanding why you want to do this would assist in providing an answer that matches the root problem rather than merely trying to address the symptoms of the current implementation.

  • if using partials you really need to specify label positions directly for polygons usually the centroid is good, for lines it's harder to determine a "good" place automatically, – Ian Turton Feb 17 '17 at 9:29
  • In my case the "Partials" vendor option was all I needed. Thanks so much! – FunkMonkey33 Feb 21 '17 at 21:12
  • It is still rendering a bit differently (i.e. more labels for WMS url), but it is much better, and the labels that are rendered with WMS are at least also rendered with WMS). – FunkMonkey33 Feb 22 '17 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.