<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Very nice explanations!<br>
The Wiki page explains the problem quite well.<br>
I wish I had found that page a long time ago.<br>
<br>
Just to carve it in stone, I would like my layer stack to look like
this:<br>
<br>
[Vector] -> OpenLayers vector layer<br>
[Selection] -> Transparent PNG, rendered dynamically by MapGuide<br>
[Dynamic Overlay] -> Main layer with bounds, etc. Also displays
thematics from MapGuide, eg Election districts.<br>
[Base layer 1] -> Transparent PNG with things like lakes etc that
are not easily visible on an aerial<br>
[Base layer 2] -> Transparent PNG with things building outlines,
road names etc.<br>
[Base layer 3] -> Aerial JPG (opaque)<br>
<br>
This enables the user to turn off building outlines without having to
reload the aerial. <br>
It also enables the user to toggle different thematics on and off
without reloading the aerial or building outlines.<br>
(It obviously costs more server calls to have the division).<br>
<br>
As I see it, my "Vector" and "Selection" are clearly overlays, where as
the "Dynamic Overlay" is the main layer.<br>
Currently I have to assign this as the "baseLayer" because it has all
the required info (units, bounds, etc.)<br>
Then I have to manually keep track of the "Base layer ?" layers z-index.<br>
<br>
I actually add the layers with the "isBaseLayer" set to true to get the
correct z-index, and then I force the<br>
layer visibility manually. This has the problem I reported here:<br>
<a class="moz-txt-link-freetext" href="http://trac.openlayers.org/ticket/1551">http://trac.openlayers.org/ticket/1551</a><br>
(For wich I now have an explanation)<br>
<br>
Perhaps a real solution would be to follow the tracks of:<br>
<a class="moz-txt-link-freetext" href="http://trac.openlayers.org/ticket/1096">http://trac.openlayers.org/ticket/1096</a><br>
But add a property named "isBottomLayer" instead to allow compatibility
with the existing code.<br>
The property should then be default "false".<br>
The only change would then be the setLayerZIndex function that checks
for this flag:<br>
<br>
setLayerZIndex: function (layer, zIdx) {<br>
layer.setZIndex(<br>
<br>
this.Z_INDEX_BASE[layer.isBaseLayer ? 'BaseLayer' :
(layer.isBottomLayer ? 'BottomLayer' : 'Overlay')]<br>
+ zIdx * 5 );<br>
},<br>
<br>
And this change to the Z_INDEX_BASE:<br>
Z_INDEX_BASE: {<br>
BottomLayer : 100<br>
BaseLayer: 200,<br>
Overlay: 425,<br>
Feature: 825,<br>
Popup: 850,<br>
Control: 1100<br>
},<br>
<br>
This should have a minimum of impact on existing implementations until
v. 3.0 gets the<br>
full fix.<br>
<br>
<pre class="moz-signature" cols="72">Regards, Kenneth Skovhede, GEOGRAF A/S
</pre>
<br>
<br>
Christopher Schmidt skrev:
<blockquote cite="mid:20081119182636.GB22425@metacarta.com" type="cite">
<pre wrap="">On Wed, Nov 19, 2008 at 12:55:31PM -0500, Paul Spencer wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Kenneth,
in a simplistic view of the world, there are two types of layers that
OpenLayers deals with - opaque and non-opaque. Opaque layers will
obscure anything 'beneath' them because they are ... er, opaque ;)
This is what OpenLayers calls a base layer. Because only one can be
seen at a time, all base layers are considered to be mutually
exclusive and non-visible ones are turned off for performance reasons.
I don't believe that modifying OpenLayers to add another type of layer
will benefit the code base at all. I don't think it is clear to me
why the current way OpenLayers works is making it difficult for you to
do what you want to do. Could you explain your use case please?
</pre>
</blockquote>
<pre wrap=""><!---->
It's pretty simple:
* I have OAM and OSM on my map.
* I want to be able to turn either of them on or off (like overlays)
* I don't have another 'base' layer which defines the projection.
Essentially, these types of 'base' layers -- layers which are always at
the bottom, no matter how they're added to the map -- don't exist.
Instead, they have to be 'overlays' over a dummy base layer, and they
have to be added first (or setLayerIndex has to be called to move them
to the bottom of the stack).
Kenneth's argument is that there should be a set of selectable layers
which lives at the bottom of the stack, but don't always need to be on.
In 3.0, I expect that all of this will be refactored -- at the very
least, it's one of the things that I know Tim has mentioned as a
significant problem for him in working with OpenLayers.
Some of the tickets related to this:
<a class="moz-txt-link-freetext" href="http://trac.openlayers.org/ticket/354">http://trac.openlayers.org/ticket/354</a>
<a class="moz-txt-link-freetext" href="http://trac.openlayers.org/ticket/1096">http://trac.openlayers.org/ticket/1096</a>
And a long, descriptive wikipage:
<a class="moz-txt-link-freetext" href="http://trac.openlayers.org/wiki/three/RemoveOverlayBaseLayerDichotomy">http://trac.openlayers.org/wiki/three/RemoveOverlayBaseLayerDichotomy</a>
Essentially, the baselayer/overlay dichotomy is weird. If yu want, you
can ignore it completely. If you do, there are some things you have to
do -- like adding the layers you want displayed at the bottom first. It
sounds to me like Kenneth is suggesting we change this. It seems likely
to me that none of this is going to change -- especially given that he
already sounds like he has a workaround -- before 3.0, but that doesn't
make his complaint wrong. Our baselayer/overlay dichotomy is weird, and
at some point, we should fix it.
Just not today.
Regards,
</pre>
</blockquote>
</body>
</html>