Let srs/crs param override projection

[ahocevar]

See http://openlayers.org/pipermail/users/2010-July/018738.html

[ahocevar]

With the above patch, people should be able to do something like this:

var wms = new OpenLayers.Layer.WMS("spherical_mercator", "http://path/to/wms",
    {
        srs: "EPSG:102113"
    }, {
        projection: new OpenLayers.Projetion("EPSG:900913");
    }
);

params.SRS will be sent to the WMS, options.projection will be used internally.

Feedback appreciated.

[ahocevar]

proof of concept

[crschmidt]

One of the few things that works at the moment for reprojection is that WMS layers will reproject to whichever base layer they are displayed over.

So far as I can tell, this patch changes that behavior; no matter what the baseLayer projection is, the map will be requested in 102113.

Additionally, I have seen many users who put the SRS in the layer parameters (not knowing that they don't need to), then change the projection of their base map; so far as I can tell, this would cause such (incorrect, but currently working) maps to break.

Are these two statements true? I'm willing to let the latter go -- it's obviously incorrect to do this in the first place -- but I'm curious about how you see the first changing going forward. In OL 3.0, we want to allow the map's projection to be changed on the fly (at least, I think that's a reasonable desire that some of us agree on.) Assuming that it's possible to change the map projection, how would the WMS layer handle the changed projection?

[ahocevar]

Replying to crschmidt:

One of the few things that works at the moment for reprojection is that WMS layers will reproject to whichever base layer they are displayed over. So far as I can tell, this patch changes that behavior; no matter what the baseLayer projection is, the map will be requested in 102113.

That's true. But it is because the user wants it this way if she provides a SRS/CRS param :-).

Additionally, I have seen many users who put the SRS in the layer parameters (not knowing that they don't need to), then change the projection of their base map; so far as I can tell, this would cause such (incorrect, but currently working) maps to break.

I have seen that too, and I keep telling people to not do it.

Are these two statements true? I'm willing to let the latter go -- it's obviously incorrect to do this in the first place -- but I'm curious about how you see the first changing going forward. In OL 3.0, we want to allow the map's projection to be changed on the fly (at least, I think that's a reasonable desire that some of us agree on.) Assuming that it's possible to change the map projection, how would the WMS layer handle the changed projection?

If we encourage a GetCapabilities->GetMap workflow, we know the available projections for a layer. OpenLayers should know all common aliases for EPSG:900913 and have a Projection.equals method. With that we can find one of the layer's available projections to use with a given map projection.

[ahocevar]

Replying to ahocevar:

If we encourage a GetCapabilities->GetMap workflow, we know the available projections for a layer. OpenLayers should know all common aliases for EPSG:900913 and have a Projection.equals method. With that we can find one of the layer's available projections to use with a given map projection.

This means that in 3.0, a layer should know all projections it can be requested in. I am envisioning a metadata option, which holds this and other extra information from GetCapabilities, but can also be populated by the developer if she does not want to do a GetCapabilities request. This would be similar to GeoExt's WMSCapabilities store.

[crschmidt]

Can we move closer to that here without going whole hog? I don't want to make you sketch out a big chunk of 3.0 functionality for a minor functionality change like this, but perhaps something in a similar direction?

I guess this only breaks the functionality I care about if users are setting SRS in their layer options, which (up until now) has been "Just Wrong", so if we don't actually want to put that functionality in now, I'm willing to let this pass (but please do add a note to the  http://trac.openlayers.org/wiki/Release/2.10/Notes page).

[ahocevar]

Marking as invalid, and suggesting #2914 as better alternative.