Steven,
Brainstorming on this topic, without having thought through all the details:

* A baselayer by definition is not transparent. Right? In that case, in 
MapPaneOL, we should be able to render all the layers until we get to 
the baselayer, then we don't render the rest. (Will be slightly more 
complicated as I think rendering happens bottom layer first).

* So we should be able to define the baselayer as the topmost layer 
which is of baselayer type (Google/MSN/...). And hence we could get away 
without needing to define a @baselayer attribute in the Context. Right?  
We may still have a baselayer variable in OWSContext.js for convenience.

* Following on from this, we shouldn't need radio buttons in the Legend. 
(This doesn't sit well with me from a user point of view). The user 
should just see layers and shouldn't have to understand that some layers 
can only be baselayers.
In the background, we just don't render any layer below the baselayer.

Steven M. Ottens wrote:
> Hi all,
>
> While refactoring MapPaneOL to accomodate non-wms baselayers I 
> discovered that I missed an important problem during the last discussion:
> If we have multiple baselayers we will need a solution similar to OL's 
> list of baselayers:
> We need to parse all layers in the context doc and pick those that are 
> baseLayers and add them to a separate list and remove them from the 
> normal layerlist and show them in a separate list with only radiobuttons.
> The resulting behavior will be similar to the mapViewer example:
> In the layerControl you get two type of layers:
>   checkbox'ed    normal layers
>   radiobutton'ed baselayers.
>
> Ticking a radiobutton will result in a setBaseLayer call which will 
> replace the current baselayer by the one ticked.
> This will mean that we need support for baselayer-radiobuttons in Legend 
> and LayerControl, a setBaseLayer function in (OWS)Context and possibly 
> rewrite the setOpaqueLayer in the mapViewer example to use setBaseLayer 
> (since it is typical baselayer behavior it's showing)
>
> However! if we do this, we need to store which layers are baselayers in 
> the context, or parse them each time which isn't a good idea since it 
> will exclude all non-baselayer-only layers. So the question is how are 
> we going to do it. The mapViewer example uses the opaque attribute:
>         <Layer queryable="1" hidden="1" opaque="1">
> which to my knowledge isn't part of the official WMC spec.
> I'm fine with using @opaque or @baselayer, which seems a better name 
> tbh. But it will break the specs.
>
> Alternatively we can:
> 2. just parse the context and hope that there's only 1 baselayer and run 
> into trouble when there are multiple
> 3. parse the context for baselayers and create a dynamic baselayerlist 
> which requires every widget/tool/model who uses layerlists to reparse it 
> to check for baselayers
>
> I propose to hijack the WMC/OWSContext and add an extra attribute. Since 
> the attribute is typically only required when there's a baselayer-only 
> layer, eg. gmaps which isn't part of the WMC anyway. If there's no 
> attribute set we will use the invisible empty wms layer as baselayer. 
> This means that valid WMC docs cannot use GMAP layers and we need to 
> introduce the @baselayer attribute to OWSContext to make sure that it 
> will be valid to use it.
>
> Steven
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> mapbuilder-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
>
>   


-- 
Cameron Shorter
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Think Globally, Fix Locally
Commercial Support for Geospatial Open Source Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
mapbuilder-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel

Reply via email to