OpenLayers OpenLayers

Ticket #686 (closed feature: fixed)

Opened 1 year ago

Last modified 8 months ago

Treat Google Layer as projected data

Reported by: euzuro Assigned to:
Priority: blocker Milestone: 2.5 Release
Component: general Version: 2.4 RC2
Keywords: Cc:
State:

Description (Last modified by crschmidt)

Currently, Google is treated inside OpenLayers as unprojected data. However, the data is actually projected - it's simply that the API which exposes that data is not. Instead of trying to work with projected data as if it is unprojected, we should treat it as projected, and talk to the API in the language that it understands.

This would resolve a number of issues that we have had over and over again with the Google layer not fitting into line with the way the rest of OpenLayers works.

Tim Schaub has started work on this in the 'google' sandbox, via the GoogleMercator layer. This work should be extended to be a base class against which we can subclass the other layers, similar to the EventPane or FixedZoomLevels mixins.

Attachments

openlayers-google.patch (4.2 kB) - added by euzuro on 04/27/07 11:12:49.
sphericalmercator.patch (33.0 kB) - added by crschmidt on 08/31/07 16:09:34.
spherical-mercator.patch (32.1 kB) - added by crschmidt on 09/11/07 16:29:28.

Change History

04/27/07 11:12:49 changed by euzuro

  • attachment openlayers-google.patch added.

05/01/07 13:47:44 changed by tschaub

07/15/07 11:39:01 changed by crschmidt

  • description changed.
  • summary changed from Adapt WMS Overlay to Google Layer to Treat Google Layer as projected data.

I think that Tim's solution here is the more appropriate one. I'd like to propose we move forward with that, rather than the zoom-level based hack that everyone seems to use.

08/03/07 10:19:07 changed by crschmidt

  • priority changed from minor to blocker.

08/31/07 16:09:34 changed by crschmidt

  • attachment sphericalmercator.patch added.

08/31/07 16:12:33 changed by crschmidt

Add SphericalMercator mixin. Use sphericalmercator mixin on all current commercial layers. Create a bunch of examples. Add a few tests.

(follow-up: ↓ 6 ) 08/31/07 16:18:49 changed by crschmidt

  • keywords set to review.

I don't know how much testing we want to do on this, but I'm tapped out on it: for now, marking review just to garner comments from anyone interested in the code. This is just a diff between http://dev.openlayers.org/sandbox/tschaub/google/ and trunk -- The code can be checked out from:

http://svn.openlayers.org/sandbox/tschaub/google/

and the way you use it is to set:

sphericalMercator: true

as an option on the layer.

I think this is going to be the final API: the GoogleMercator layer is going to go away, and it's just going to be an option on the layer.

(in reply to: ↑ 5 ) 09/11/07 15:52:53 changed by elemoine

Replying to crschmidt:

I don't know how much testing we want to do on this, but I'm tapped out on it: for now, marking review just to garner comments from anyone interested in the code. This is just a diff between http://dev.openlayers.org/sandbox/tschaub/google/ and trunk -- The code can be checked out from: http://svn.openlayers.org/sandbox/tschaub/google/ and the way you use it is to set: sphericalMercator: true as an option on the layer. I think this is going to be the final API: the GoogleMercator layer is going to go away, and it's just going to be an option on the layer.

I've just taken a look at the patch. Excellent work. One comment: your patch adds GoogleMercator.js to the js list in OpenLayers.js, which, I guess, is not something you want in the final patch.

09/11/07 16:29:28 changed by crschmidt

  • attachment spherical-mercator.patch added.

09/11/07 16:31:08 changed by crschmidt

Removed googlemercator.js from OpenLayers.js

09/11/07 17:16:41 changed by crschmidt

  • keywords deleted.
  • status changed from new to closed.
  • resolution set to fixed.

(In [4221]) With review from elem, and oversight from tschaub, rolling in SphericalMercator changes. Note that this explicitly does *not* include r4182 , so as to keep changes to a single logical set: that should be filed in a seperate bug if it can be reproduced against trunk after this commit. Hooray for Tim, thanks for all the feedback, onward and upward! (Closes #686)