Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.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.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | wms_baselayer_900913_projection_878644_18.patch | 530 bytes | batje |
| #13 | wms_baselayer_900913_projection.patch | 517 bytes | batje |
| #6 | wms.patch | 1.91 KB | batje |
Comments
Comment #1
batje CreditAttribution: batje commentedAfter 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
Comment #2
tmcw CreditAttribution: tmcw commentedIs this a different issue than #878662: Using wms & geowebcache as a baselayer resolution issues?
Comment #3
batje CreditAttribution: batje commentedyes 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)
Comment #4
tmcw CreditAttribution: tmcw commentedThe 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.
Comment #5
batje CreditAttribution: batje commentedlet me study that code & the wiki a bit more.
Comment #6
batje CreditAttribution: batje commentedOk, 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
Comment #7
batje CreditAttribution: batje commentedComment #8
tmcw CreditAttribution: tmcw commentedPath 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
Comment #10
strk CreditAttribution: strk commentedNote: 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
Comment #11
strk CreditAttribution: strk commentedThe #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.
Comment #12
tmcw CreditAttribution: tmcw commentedYou'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.
Comment #13
batje CreditAttribution: batje commentedindeed, 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.
Comment #14
batje CreditAttribution: batje commentedForgot to re-open and wms is more accurate as a tag than geoserver.
Comment #15
strk CreditAttribution: strk commentedCommitted the meters units: http://drupal.org/cvs?commit=433452
Is there anything left in this ticket ?
Comment #16
batje CreditAttribution: batje commentedThis ticket is now officially over, closed and fixed with. thanks all.
Comment #17
batje CreditAttribution: batje commentedand there is even a status for that.
Comment #18
batje CreditAttribution: batje commentedPatch #13 disappeared from the D7 version of OpenLayers, and we found it again.
Here is a patch for 7.x-2-dev
Comment #19
mgiffordPatch applies nicely. Look forward to seeing it in the next dev release.
Comment #20
zzolo CreditAttribution: zzolo commentedThanks for the patch, @batje. Sorry about the delay.
http://drupalcode.org/project/openlayers.git/commit/b3c4630
Comment #21
batje CreditAttribution: batje commentedHi 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.