Ticket #3058 (closed feature: fixed)

Opened 2 years ago

Last modified 2 years ago

Use correct maxResolution for Web Mercator

Reported by: ahocevar Owned by:
Priority: minor Milestone: 2.11 Release
Component: general Version: 2.10
Keywords: Cc:
State: Complete

Description

In all our layer types that pre-configure the maxResolution for Spherical Mercator, we use 156543.0339. The  WMS Tiling Client Recommendation, however, defines a maxResolution of 156543.03390625 (20037508.34 / 128).

With our current maxResolution settings, when working with layers configured from a WMS-C GetCapabilities doc, which advertises the highest resolution as 156543.03390625, this may result in layers being out of range at the highest resolution.

Attachments

openlayers-3058.patch Download (2.9 KB) - added by ahocevar 2 years ago.
openlayers-3058.2.patch Download (4.3 KB) - added by ahocevar 2 years ago.
modified Google.v3 tests to expect what should be expected - but tests still fail
openlayers-3058.3.patch Download (6.4 KB) - added by ahocevar 2 years ago.
use parseFloat and OpenLayers.LonLat to have our expected values truncated to OpenLayers.Util.DEFAULT_PRECISION
openlayers-3058.4.patch Download (8.0 KB) - added by ahocevar 2 years ago.
overriding OpenLayers.Util.DEFAULT_PRECISION, and Google.v3 tests pass

Change History

Changed 2 years ago by ahocevar

Changed 2 years ago by ahocevar

All tests still pass. Thanks for any review.

Changed 2 years ago by bartvde

  • state changed from Review to Needs More Work

Hi Andreas, Google/v3 tests fail with this patch.

Btw, I was quite amazed at how many occurrences this constant has in the code base, but that's a side note.

Changed 2 years ago by ahocevar

Hm. This happens when running tests without clearing the cache first. There are 3 different reasons for failing tests:

  • Tests expecting 20037508.3392 as center lon ("edge of the world") should expect 20037508.34. This is because of the definition of the map resolutions (see above). With this change, these tests pass.
  • The test that expects -12210356.6442 should now expect 100 * map.getResolution() - 20037508.34. Unfortunately the test still fails after this change.

* The remaining failing tests fail because of values incorrect at a magnitude of 1e-8.

The interesting thing is: when setting OpenLayers.Util.DEFAULT_PRECISION = 0;, all tests pass. So I suspect that somewhere in the chain we should use OpenLayers.Util.toFloat where we currently don't.

This needs further investigation.

Changed 2 years ago by ahocevar

modified Google.v3 tests to expect what should be expected - but tests still fail

Changed 2 years ago by ahocevar

use parseFloat and OpenLayers.LonLat to have our expected values truncated to OpenLayers.Util.DEFAULT_PRECISION

Changed 2 years ago by ahocevar

With openlayers-3058.3.patch Download, all tests pass when OpenLayers.Util.DEFAULT_PRECISION is set to 13. It seems that GMap v3 uses a precision of 13 internally.

Changed 2 years ago by bartvde

Hi Andreas, I can confirm this, would it not make sense to change the test script to use a precision of 13, and then change it back to the original value when the tests are done? So that at least the test passes out of the box.

Changed 2 years ago by ahocevar

  • state changed from Needs More Work to Review

@bartvde: Sounds good. I created #3059 for the problem that Layer.Google.v3 uses a different default precision than openlayers.

Now all tests pass. Thanks again for any review.

Changed 2 years ago by ahocevar

overriding OpenLayers.Util.DEFAULT_PRECISION, and Google.v3 tests pass

Changed 2 years ago by bartvde

  • state changed from Review to Commit

Thanks for digging into this ahocevar, looks good to me now, please commit.

Changed 2 years ago by ahocevar

  • status changed from new to closed
  • state changed from Commit to Complete
  • resolution set to fixed

closed by r11118 (use the correct maxResolution of 156543.03390625. r=bartvde)

Note: See TracTickets for help on using tickets.