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

[Matt Priour]

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

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.

Matt Priour
Kestrel Computer Consulting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20100923/feedfe68/attachment.html