[OpenLayers-Dev] [OpenLayers 3] code sprint summary,
and request for comments
Dan Little
danlittle at yahoo.com
Fri Sep 17 09:01:35 EDT 2010
I'm hoping this is a semi-appropriate thread to make this
suggestion/recommendation. Please feel free to use corporal punishment if it is
not.
For layers like WMS, which can actually have multiple "sub layers" it would be
nice to have the ability to provide some level of control. In my two primary
applications (LEHD OnTheMap and GeoMOOSE) we have to do some work-arounds to
make this happen cleanly. The two best use cases for this are:
1) Putting many of the labels into a single WMS image request. With MapServer
this has a significant effect on how cleanly the labels render. At the same
time, the user may not want to see all the labels for every layer all of the
time.
2) Variable basemaps. Again, if a basemap has 10-12 layers in it and the user
wishes to turn one of them off it's not efficient to transfer 10-12 separate
images "just in case" the user decides to turn one of these layers off.
Of course, triggering an event when one of these "layers" is turned on or off is
even better. :-)
I'm certainly willing to contribute some code as I do have a fairly clean
implementation for doing this. It was written "under fire" and as my own class
for my own application.
I should maybe g'head and try and sign that code contribution form.
----- Original Message ----
> From: Eric Lemoine <eric.lemoine at camptocamp.com>
> To: dev at openlayers.org
> Sent: Fri, September 17, 2010 6:33:41 AM
> Subject: [OpenLayers-Dev] [OpenLayers 3] code sprint summary, and request for
>comments
>
> 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 x 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
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>
More information about the Dev
mailing list