id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,state
2268,WMS layer incorrectly positioned over Google base map layer at small scales,dgoodwin,euzuro,"When displaying a single tile WMS layer over a Google base map at a small enough scale to see the entire world, the WMS layer gets shifted far to the right and the features we are trying to overlay are not visible as they are now outside the viewport.  Generally, zooming in one level will correctly position the WMS layer over the base map. (see attached screenshots of Firebug displaying the positioning of the WMS layer)

Actually, this problem occurs with any base map that horizontally repeats the world view at small scales (Google or Yahoo) but is not an issue with base maps that always show a single world map (Bing or OpenStreetMap).

By stepping through the code in Firebug, I have identified where the problem occurs and why, but I would like to know if there is an existing fix or a workaround that can be used without modifying the source code.

Essentially, this is what is occurring in my specific instance:

In the following code snippet from the '''initSingleTile''' function of '''OpenLayers.Layer.Grid''', we can see that the pixel location of the upper left corner of the tile image is being computed and then used to position the tile via a call to {{{tile.moveTo}}}

{{{
    var ul = new OpenLayers.LonLat(tileBounds.left, tileBounds.top);
    var px = this.map.getLayerPxFromLonLat(ul);

    if (!this.grid.length) {
        this.grid[0] = [];
    }

    var tile = this.grid[0][0];
    if (!tile) {
        tile = this.addTile(tileBounds, px);
        
        this.addTileMonitoringHooks(tile);
        tile.draw();
        this.grid[0][0] = tile;
    } else {
        tile.moveTo(tileBounds, px);
    }           
}}}
Following the code a few frames deeper into the stack during the call to {{{this.map.getLayerPxFromLonLat(ul)}}} reveals the code to translate the upper-left corner of the WMS layer extent from lon/lat to a pixel, in the following function from '''OpenLayers.Layer.EventPane''':
{{{
getViewPortPxFromLonLat: function (lonlat) {
    var viewPortPx = null;
    if ( (this.mapObject != null) && 
         (this.getMapObjectCenter() != null) ) {

        var moLonLat = this.getMapObjectLonLatFromOLLonLat(lonlat);
        var moPixel = this.getMapObjectPixelFromMapObjectLonLat(moLonLat);
    
        viewPortPx = this.getOLPixelFromMapObjectPixel(moPixel);
    }
    return viewPortPx;
}
}}}

This in turn eventually calls the function '''getMapObjectLonLatFromLonLat''' in the actual Google layer class '''OpenLayers.Layer.Google''':
{{{
getMapObjectLonLatFromLonLat: function(lon, lat) {
    var gLatLng;
    if(this.sphericalMercator) {
        var lonlat = this.inverseMercator(lon, lat);
        gLatLng = new GLatLng(lonlat.lat, lonlat.lon);
    } else {
        gLatLng = new GLatLng(lat, lon);
    }
    return gLatLng;
}
}}}

First, the coordinate in spherical mercator (metres) is converted to a lon/lat through the inverseMercator transform, which returns a lon/lat of (roughly) (-301.9, 85.735).  This is then used to create a GLatLng in the Google API.  But during this GLatLng creation process the original lon/lat is returned as (58.1, 85.735) (i.e. +360 degrees longitude).  This value is returned to '''getViewPortPxFromLonLat''' as '''moLonLat''' which is translated to a pixel coordinate via the call:
{{{
var moPixel = this.getMapObjectPixelFromMapObjectLonLat(moLonLat);
}}}
The pixel returned is (y=-178, x=738) causing the layer to be shifted way to the right.  In any normal situation, the x-value should always be negative to represent the fact that the upper-left corner of the tile is above and to the left of the viewport.  And, in fact, that is what always happens at larger scales, causing correct alignment of the layers.

Anyway, I feel that this is a bug in OpenLayers that should be eventually addressed.  In the meantime, I would appreciate any ideas or feedback from anyone on coding a workaround.",bug,new,minor,2.13 Release,Tile.Image,2.8,,,dgoodwin@…,
