[OpenLayers-Dev] [OpenLayers 3] code sprint summary,
and request for comments
Eric Lemoine
eric.lemoine at camptocamp.com
Fri Sep 17 07:33:41 EDT 2010
Hi all.
A few days ago I wrote a blog post [1] to present what some of us
worked on for OpenLayers 3 during the FOSS4G code sprint in Barcelona.
We didn't write any code during the code sprint, but just discussed
new APIs and design. With this email I'd like to provide more
technical details, and hopefully generate discussions, and get ideas
and opinions.
My apologies for the lengthy email. Feel free to create new discussion
threads for specific topics if you find it more appropriate. And all
this is to be discussed, so any comments, questions, criticisms are
very welcome.
[1] <http://www.camptocamp.com/fr/blog/2010/09/2181/>
OL 2.x issues
===========
Baselayers and overlays
----------------------------------
We currently have baselayers and overlays. Baselayers are mutually
exclusive, and the map must have at least one. The current baselayer
is where the resolutions, maxExtent and projection are set, so the map
always gets the resolutions, maxExtent and projection from the current
baselayer when it needs them.
This baselayer/overlay paradigm can be problematic. For example, for a
given set of layers, the user may want to be able to turn on any
number of them (including none), and to display them in any order. To
be able to do that people have been using a fake base layer, which
isn't intuitive, at best.
The allOverlays option can help, but there are still cases where it
doesn't, because there still is one layer (the one at index 0) with
more priviledge than the others.
Another issue is that we initialize/calculate resolutions for any
layer added to the map, because any layer can potentially be a
baselayer, that is especially true when allOverlays is set (the layer
at index 0 is the current baselayer from the map perspective).
Map reprojection
------------------------
OpenLayers 2.x doesn't support reprojecting the map, and lots of
people have been asking for it. Some efforts have been done towards
this ([2] [3]), but simple and convenient APIs do not exist.
[2] <http://trac.openlayers.org/browser/sandbox/elemoine/reproject/examples/reproject-map.html>
[3] <http://dev.openlayers.org/sandbox/elemoine/reproject/examples/reproject-map.html>
Complex APIs
---------------------
Creating a simple map with a layer may require quite some code and
knowledge from the application developer. This is particularly true
when working with spherical mercator layers, where (a) the map must be
configured with an EPSG:900913 projection and a maxExtent expressed in
that projection, and (b) the layer must have sphericalMercator set to
true.
Proposal for OL 3.x
================
Removing baselayer/overlay dichotomy
-------------------------------------------------------
We've been thinking about removing the baselayer/overlay paradigm.
Essentially, the map would be the place where the projection,
resolutions, and maxExtent are set, and all the layer would be equal.
In this way, any layer could be turned on/off, and layers could be
arranged in any order. In this design the map is the central place,
and layers are "secondary" objects that adapt to the map.
Map reprojection
------------------------
Regarding map reprojection we've talked about introducing a
setProjection method to the map. setProjection would reconfigure the
map with the new projection, and gives each layer present in the map a
chance to adapt (for example WMS layers would request new images from
their WMS servers). Layers that cannot adapt would be turned off.
Note: we may want to have "reconfigure" instead of "setProjection", as
not only does map reprojection involve setting a new projection, it
also involves setting new resolutions. I'm thinking about something
like map.reconfigure({projection: "EPSG:4326", maxResolution:
1.40625});
Simpler APIs
-------------------
For example, to create and display a map with a Google layer, we would
like to be able to just do this:
new OpenLayers.Map({
div: "map",
layers: new OpenLayers.Layer.Google()
center: [0, 0]
});
Likewise, to create and display an EPSG:4326 map with a WMS layer we'd like:
new OpenLayers.Map({
div: "map",
layers: new OpenLayers.Layer.WMS()
center: [0, 0]
});
Comments and code design
=======================
In the proposed design, for layers to be turned on and off based on
the current projection, layers advertize the projections they support.
For example, Google layers advertize "EPSG:900913", vector layers
advertize no projection, meaning they support all projections.
In most cases the projection would be configured and set in the map,
and application developers would be encouraged to configure a map with
a projection. But, to be able to support
new OpenLayers.Map({
div: "map",
layers: new OpenLayers.Layer.Google()
center: [0, 0]
});
we could introduce a kind of fallback mechanism, where the map gets
the projection from the first layer (the one at index 0 in the layers
array) when it has no projection itself.
So, the Map class would use this.getProjection() to get the current
projection, and getProjection would be something like this:
getProjection: function() {
return this.projection ||
(this.layers.length > 0 && this.layers[0].projection) ||
this.defaultProjection;
}
(with defaultProjection being set to "EPSG:4326" in the map).
The above design would require taking action when the layer at index 0
is removed or replaced. For example, if we have
new OpenLayers.Map({
div: "map",
layers: [
new OpenLayers.Layer.Google(),
new OpenLayers.Layer.WMS()
],
center: [0, 0]
});
and if the Google layer is removed, a reprojection from EPSG:900913 to
EPSG:4326 will need to occur.
But again, I think that the case where no projection is set in the map
should the exception rather than the rule, it should be seen as a
convenience for creating a map with a minimum of configuration. So,
typically, the above example would look like this:
new OpenLayers.Map({
div: "map",
projection: "EPSG:900913",
layers: [
new OpenLayers.Layer.Google(),
new OpenLayers.Layer.WMS()
],
center: [0, 0]
});
And in that case removing the Google layer wouldn't lead to a
reprojection, the projection will remain EPSG:900913 until an explicit
setProjection to some other projection is performed by the application
code.
Okay, that's all for today.
--
Eric Lemoine
Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex
Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine at camptocamp.com
http://www.camptocamp.com
More information about the Dev
mailing list