<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=iso-8859-1>
<META content="MSHTML 6.00.6002.18278" name=GENERATOR></HEAD>
<BODY id=MailContainerBody
style="PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px" leftMargin=0
topMargin=0 CanvasTabStop="true" name="Compose message area">
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I think the common use cases are for maps with a
background layer are:</FONT></DIV>
<DIV><FONT face=Arial size=2>1. Fixed resolution, fixed
projection tile sets in "Google Maps" configuration</FONT></DIV>
<DIV><FONT face=Arial size=2>2. Fixed resolution, fixed projection tile sets in
a local coordinate system and/or non-Google tiling scheme</FONT></DIV>
<DIV><FONT face=Arial size=2>3. WMS free resolution, free projection
background</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Matt Priour</FONT></DIV>
<DIV><FONT face=Arial size=2>Kestrel Computer
Consulting</FONT></DIV></BODY></HTML>