[OpenLayers-Dev] Re: [OpenLayers 3] code sprint summary, and

Eric Lemoine eric.lemoine at camptocamp.com
Fri Sep 24 08:49:14 EDT 2010


Hi Matt,

On Fri, Sep 24, 2010 at 6:19 AM, Matt Priour
<mpriour at kestrelcomputer.com> wrote:
> Following the discussion between Paul & Eric has really shown the dichotomy
> of opinions regarding the map vs layers as master controller and reveals the
> reason for the baseLayer paradigm in the first place.
>
> I think the common use cases are for maps with a background layer are:
> 1. Fixed resolution, fixed projection tile sets in "Google Maps"
> configuration
> 2. Fixed resolution, fixed projection tile sets in a local coordinate system
> and/or non-Google tiling scheme
> 3. WMS free resolution, free projection background
>
> Using any of these by themselves is generally pretty easy and makes little
> difference to most users if the map or a base layer controls the map
> properties. Admittedly it is confusing to configure your map and your base
> layer with similar options but no direct documentation that the base layer
> wins in nearly all options and overwrites whatever you have for your map as
> is the case in OL 2. For these users, there is no question that moving the
> configuration to the map makes more sense.
>
> The problems start happening when users want to mix and match the 3
> background types and switch easily between them. The real issue is what
> object will add a reconfigure map event to the map.
>
> With Paul's proposal of the map object is in absolute control of all of the
> layers that it displays and convenience functions that do "magic" map
> reconfiguration should be moved to preconfigured event handlers in map
> configuration options or even further removed all the way out to UI
> controls.
>
> With Eric's proposal, you get the magic map reconfiguration behavior added
> in when you set a layer configuration option indicating that it is a
> "Master" layer.
>
> I think fundamentally at a basic underlying code level the 2 proposals are
> quite similar. However, there is a big difference in the API depending on
> which way you go. I personally think that setting the map as a Google style
> map makes the mixing of background layer types, too difficult for novice API
> users.

Yes, I've been wondering how to address the following case with Paul's proposal:

new OpenLayers.Map({
    layers: [
        new OpenLayers.Layer.Google(),
        new OpenLayers.Layer.Yahoo(),
        new OpenLayers.Layer.TileCache({
            resolutions: [...],
            projection: ...
        })
    ]
});

With my proposal the three layers would be placed in the "master"
group (which could be the default for the commercial layers), and
switching from Yahoo or Google to TileCache, or vice-versa, would
trigger a map reprojection (obviously if the TileCache layer's
projection isn't 900913).

> I also think that configuring the map with a set of valid
> resolutions, maxExtent, projection combinations and having to include layers
> that match at least one of those combinations in the map makes the API much
> less straight-forwar.

FYI, during the code sprint, we also mentioned introducing a lookup
table that provides default values for maxResolution and maxExtent for
EPSG:4326 and EPSG:900913 (the two keys of the table).


> I would propose that _Yes_ the map is the one that controls all the other
> layers and anytime you reconfigure the map it should reconfigure those
> layers that it can and stop displaying / disable the layers that it can not.
> However, I think it makes a lot of sense from an API point to have a Master
> layer type option. Basically all this layer has is a preconfigured event
> handler that listens for the setVisiblity event and fires a reconfigure map
> function using the layer's projection, resolutions , and maxExtent options.
> However, unlike in Eric's proposal, any other layers configured as Master
> layers would only get turned off / disabled if they were incompatible with
> the reconfigured map. I think the automatic turning on/off of compatible
> layers and the idea of layer groups IS better handled by UI controls or some
> other place than the fundamental building blocks of map & layers.

I'm a bit undecided on whether OpenLayers should implement the concept
of layer group (and mutually exclusive layers). I tend to think it is
nice to have OpenLayers provide it - I guess users would certainly
like to be able to have radio buttons in their OpenLayers layer
switcher. I'll give it more thought and come back. In the meantime,
I'm obviously very interested in others' opinion.

Thank you.

-- 
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