When WMS is used to generate a baselayer in projection 900913 the tiles are not generated in the right resolution or zoomlevel.

Two minor changes to the openlayers.js fix this issue, and do not seem to have a negative impact on Google & OSM baselayers.

         if (map.projection === '900913') {
            options.maxExtent = new OpenLayers.Bounds(
              -20037508.34, -20037508.34, 20037508.34, 20037508.34);
            options.units = "m";
          }

and 3 lines further

   options.maxResolution = "auto"; //1.40625;

Not sure i understand why that maxResolution was hardcoded, so might be overlooking things.

Files: 
CommentFileSizeAuthor
#18 wms_baselayer_900913_projection_878644_18.patch530 bytesbatje
PASSED: [[SimpleTest]]: [MySQL] 236 pass(es).
[ View ]
#13 wms_baselayer_900913_projection.patch517 bytesbatje
PASSED: [[SimpleTest]]: [MySQL] 221 pass(es).
[ View ]
#6 wms.patch1.91 KBbatje
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch wms.patch.
[ View ]

Comments

Title:Using WMS as a Baselayer resolution Using WMS as a Baselayer resolution issue

After you have applied these changes, and you are moving on to use geowebcache, you will run into the next issue described here: http://drupal.org/node/878662

yes it is.

these 2 small changes make WMS work as a baselayer.

The way geowebcache deals with resolutions is different (as in, a lot less flexible) than that of pure WMS. With these 2 changes, geowebcache still totally messes up the tiles.

(there might be 1 way around this, which is to make geowebcache act as a full WMS service, that is an option you can set, but that has a very severe impact on the actual caching and thus performance. i got that from the documentation, didnt try it)

The first change is fine, and I'll roll a patch and commit that. The maxResolution setting, however, can very easily mess up existing configurations if it's changed. This terrible code in OpenLayers is the reason behind that line.

let me study that code & the wiki a bit more.

StatusFileSize
new1.91 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch wms.patch.
[ View ]

Ok, major breakthrough.

the wms.inc never did set the resolutions. While it sets an option called serverResolutions, this is never used, as the way to change a WMS layers' resolutions is by passing them in through the options array when creating a new layer. The code now assumes that setting the resolutions on the (drupal) options array will help, but it wont.

Here is the documentation (Which is incomplete, there are 4 paramers in the creator of a WMS layer, not 3)
http://trac.openlayers.org/wiki/Layer/WMS

And here is the documentation around the function you are referring to http://trac.openlayers.org/wiki/SettingZoomLevels

Attached is the patch.

(i also included 2 small fixes with the return_value for transparent & baselayer) that should have been fixed here http://drupal.org/node/862690 but didnt make it into the latest dev built)

So far, this seems to solve our issues, even the one with the geowebcache: http://drupal.org/node/878662

Status:Active» Needs review

Status:Needs review» Fixed

Path works on my end against GeoServer and GeoWebCache (although I didn't have the original problems you encountered).

Fixed in http://drupal.org/cvs?commit=408332

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Note: this commit broke isBaseLayer making it a string rather than a boolean (in JavaScript land).
Was that change (#return_value = 'true' from #return_value = TRUE) really needed ? What for ?
See http://drupal.org/node/914648 for more informations

The #return_value was changed back to a boolean by http://drupal.org/cvs?commit=423674
Next time please split your patches and make different commits for different focuses.

You'll have to ask batje about that: I simply don't have much testing ability or usage of WMS on my side, so the most I can really do is confirm whether submitted patches are functional. If you'd like to take ownership of the WMS layer type, go ahead.

Issue tags:+geoserver
StatusFileSize
new517 bytes
PASSED: [[SimpleTest]]: [MySQL] 221 pass(es).
[ View ]

indeed, with all the issues around wms, baselayers and projection, somehow the javascript return value looked like making a big difference, but it turns out it doesnt. Sorry about that. And will not mix patches too. And will create patch files for every small little change as well. Learned that too.

So here is one.

Attached is the patch for the very first issue in my original post. Adding

options.units = "m";

to the 900913 projection in the openlayers.js file.

The behaviour we see, when we do not have this defined, is that if we mix our own wms baselayer and OSM, our baselayer makes Uganda look like 10000000 kilometers wide in the scalebar. Switching from our baselayer to OSM makes the map look like you are on the moon.
With this small addition, both maps display exactly the same.

Version:6.x-2.x-dev» 6.x-2.0-alpha10
Status:Closed (fixed)» Needs review
Issue tags:-geoserver+wms

Forgot to re-open and wms is more accurate as a tag than geoserver.

Status:Needs review» Fixed

Committed the meters units: http://drupal.org/cvs?commit=433452

Is there anything left in this ticket ?

This ticket is now officially over, closed and fixed with. thanks all.

Status:Fixed» Closed (fixed)

and there is even a status for that.

Version:6.x-2.0-alpha10» 7.x-2.x-dev
Component:Layers» OL API
Status:Closed (fixed)» Needs review
StatusFileSize
new530 bytes
PASSED: [[SimpleTest]]: [MySQL] 236 pass(es).
[ View ]

Patch #13 disappeared from the D7 version of OpenLayers, and we found it again.

Here is a patch for 7.x-2-dev

Status:Needs review» Reviewed & tested by the community

Patch applies nicely. Look forward to seeing it in the next dev release.

Status:Reviewed & tested by the community» Fixed

Thanks for the patch, @batje. Sorry about the delay.

http://drupalcode.org/project/openlayers.git/commit/b3c4630

Hi Allan,

The array will work, but it will attach the SelectFeature to all layers on the map.

From code. Check the initLayer function in this javascript file:
http://dev.openlayers.org/sandbox/camptocamp/mobile/trunk/lib/openlayers...

That shows that the whole array of layers is put in a _container div (or a RootContainer vector layer).

The result of this is that the Click event on a single layer does not cancel consecutive clicks. So if you have 2 layers, and click the top one, then the click event also occurs on the second layer.

When we build a map with our geosearch module and our GetFeatureInfo functionality from the wms module and a normal Drupal layer, that was causing issues. After you clicked a search result, you did not want to also do a WMS Getfeatureinfo request as well.

This patch solved that (rather obscure) issue for us.

The reason why this is happening is that if you add 2 layers to the SelectFeature, the click event should not be cancelled by OpenLayers (well, its should, once you reach the last one, but its not implemented that way).

When you add only 1 layer, the Click event *is* cancelled by OpenLayers, which is good.

Status:Fixed» Closed (fixed)
Issue tags:-wms

Automatically closed -- issue fixed for 2 weeks with no activity.