[OpenLayers-Dev] Base Layer vs. Main layer

[Bob Basques]

All,

This topic is of special interest here.   Working on the GeoMoose package we built in this type of functionality early on.  Yes it is a server call intensive method of display, but we also put in quite a bit of work to make the data streams from the servers run fast as well.  I think the end user experience is better for it as well.  We do tend to target slightly more experienced end users, but the interfaces can be simplified easily as well.

The type of functionality you are speaking of is already built into the existing GeoMoose Framwork.  You can see it in action here on our public site:

http://gis.ci.stpaul.mn.us/gis/gismo_public/html/

Now, why am I mentioning this now, well, the GeoMoose developer team is actively building a GeoMoose future version that will be OpenLayers based, I've seen the basics already running ( I can send a screenshot ).  The same sorts of capabilities that are available in the above referenced link (which address the types of functions talked about in this thread) will be available in the newer version with OpenLayers LIBs running a good chunk of the Mapping display.

Also, one layer (type) I would add to your list (don't know if there is a OpenLayers equivalent . . .) would be a client ImageMap layer of some sort.  We use MapServer templates extensively for this type of thing right now.  Also, I wouldn't Make the stacking logic as static as you have laid out either.   We can have more than one aerial photo on at a time and fade between more than one layer at a time incrementally.

Some of the differences I'm talking about may be more related to using OpenLayers as a Client vs Openlayers as a LIB, but you all know about those differences.  

bobb

>>> "Kenneth Skovhede, GEOGRAF A/S" <ks at geograf.dk> 11/19/08 1:05 PM >>>
Very nice explanations!
The Wiki page explains the problem quite well.
I wish I had found that page a long time ago.

Just to carve it in stone, I would like my layer stack to look like this:

[Vector] -> OpenLayers vector layer
[Selection] -> Transparent PNG, rendered dynamically by MapGuide
[Dynamic Overlay] -> Main layer with bounds, etc. Also displays 
thematics from MapGuide, eg Election districts.
[Base layer 1] -> Transparent PNG with things like lakes etc that are 
not easily visible on an aerial
[Base layer 2] -> Transparent PNG with things building outlines, road 
names etc.
[Base layer 3] -> Aerial JPG (opaque)

This enables the user to turn off building outlines without having to 
reload the aerial.
It also enables the user to toggle different thematics on and off 
without reloading the aerial or building outlines.
(It obviously costs more server calls to have the division).

As I see it, my "Vector" and "Selection" are clearly overlays, where as 
the "Dynamic Overlay" is the main layer.
Currently I have to assign this as the "baseLayer" because it has all 
the required info (units, bounds, etc.)
Then I have to manually keep track of the "Base layer ?" layers z-index.

I actually add the layers with the "isBaseLayer" set to true to get the 
correct z-index, and then I force the
layer visibility manually. This has the problem I reported here:
http://trac.openlayers.org/ticket/1551
(For wich I now have an explanation)

Perhaps a real solution would be to follow the tracks of:
http://trac.openlayers.org/ticket/1096
But add a property named "isBottomLayer" instead to allow compatibility 
with the existing code.
The property should then be default "false".
The only change would then be the setLayerZIndex function that checks 
for this flag:

    setLayerZIndex: function (layer, zIdx) {
        layer.setZIndex(

            this.Z_INDEX_BASE[layer.isBaseLayer ? 'BaseLayer' : 
(layer.isBottomLayer ? 'BottomLayer' : 'Overlay')]
            + zIdx * 5 );
    },

And this change to the Z_INDEX_BASE:
    Z_INDEX_BASE: {
        BottomLayer : 100
        BaseLayer: 200,
        Overlay: 425,
        Feature: 825,
        Popup: 850,
        Control: 1100
    },

This should have a minimum of impact on existing implementations until 
v. 3.0 gets the
full fix.

Regards, Kenneth Skovhede, GEOGRAF A/S



Christopher Schmidt skrev:
> On Wed, Nov 19, 2008 at 12:55:31PM -0500, Paul Spencer wrote:
>   
>> 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?
>>     
>
> 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:
>
>   http://trac.openlayers.org/ticket/354
>   http://trac.openlayers.org/ticket/1096
>
> And a long, descriptive wikipage:
>
>   http://trac.openlayers.org/wiki/three/RemoveOverlayBaseLayerDichotomy
>
> 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,
>