GeoServer

Tiles rendering off from intended bounds?

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.7.0-RC4
  • Fix Version/s: 1.7.1
  • Component/s: WMS
  • Labels:
    None
  • Number of attachments :
    0

Description

Not sure how to reproduce this bug generally, but here's what I know:

I've been hitting http://geo.openplans.org/geoserver/gwc/service/wms with WMS requests for topp:nyc_background.

I'm getting tiles back, but at some resolutions things appear to be a little "off". I can't tell if they have been rendered with a slightly displaced bounding box, or a slightly larger one, or what. But I know that:
(a) when I overlay a vector layer on top of the map using OpenLayers, the relative positions of those vector features and the rendered features of the WMS layer change as I zoom in and out, and
(b) when I point the base layer at a different set of cached layers derived from the same data ("http://artois.openplans.org/tc/tilecache.py) I don't get the same problem.

I cleared geo's GWC cache for the topp:nyc_background layer, and it did not solve the problem.

An example of a URL that I think is giving me a bad tile is:

http://geo.openplans.org/geoserver/gwc/service/wms?LAYERS=topp%3Anyc_background&BGCOLOR=0xECECC6&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A900913&BBOX=-8232267.945167576,4979996.602257023,-8229821.960262888,4982442.5871617105&WIDTH=256&HEIGHT=256

Activity

Hide
Andrea Aime added a comment -

Sebastian, what happens if you hit GeoServer WMS directly as opposed as going thought GWC?
Arne, rings any bell?

Show
Andrea Aime added a comment - Sebastian, what happens if you hit GeoServer WMS directly as opposed as going thought GWC? Arne, rings any bell?
Hide
Sebastian Benthall added a comment -

I'm not 100% sure how the different layers of data are getting rendered together for the topp:nyc_background layer; I couldn't figure out if GS was configured with a layer group for it. But if I hit GeoServer WMS directly and ask for topp:nyc_hydrography, then I don't get the problem described in the ticket.

Show
Sebastian Benthall added a comment - I'm not 100% sure how the different layers of data are getting rendered together for the topp:nyc_background layer; I couldn't figure out if GS was configured with a layer group for it. But if I hit GeoServer WMS directly and ask for topp:nyc_hydrography, then I don't get the problem described in the ticket.
Hide
Arne Kepp added a comment -

What does the client code look like?

I'm mostly worried about maxResolution, bounds and maybe maxextent , since OpenLayers can use any one of those to calculate the resolutions.

GeoWebCache will accept requests that are within 2% of the accepted resolutions. That probably sounds generous, but it gets tricky if you zoom in and the numbers get small.

Show
Arne Kepp added a comment - What does the client code look like? I'm mostly worried about maxResolution, bounds and maybe maxextent , since OpenLayers can use any one of those to calculate the resolutions. GeoWebCache will accept requests that are within 2% of the accepted resolutions. That probably sounds generous, but it gets tricky if you zoom in and the numbers get small.
Hide
Sebastian Benthall added a comment -

maxResolution: 38.21851413574219

links to folow

Show
Sebastian Benthall added a comment - maxResolution: 38.21851413574219 links to folow
Hide
Arne Kepp added a comment -

Client was requesting incorrect bounds, but geowebcache was not failing and throwing an exception as it should have.

Both fixed, see http://projects.opengeo.org/vespucci/ticket/372

and

http://geowebcache.org/trac/ticket/53

Show
Arne Kepp added a comment - Client was requesting incorrect bounds, but geowebcache was not failing and throwing an exception as it should have. Both fixed, see http://projects.opengeo.org/vespucci/ticket/372 and http://geowebcache.org/trac/ticket/53

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: