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.lemo...@camptocamp.com http://www.camptocamp.com _______________________________________________ Dev mailing list d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-dev
