Hi again, I have a refined proposal which might be more satisfying to those of you that are in favour of a context-based solution:
IIRC, all map and layer control widgets only look for "Layer" and "FeatureType" nodes in the context. So why don't we add "BaseLayer" nodes? Since OWSContext is more or less a Mapbuilder-standard anyway (at least it is definitely not an OGC standard), we could again add an extension to it. And it makes sense, because base layers have different properties than other layers. We had a discussion about that a few days ago, and in addition to that I realized that map resolutions are strongly tied with base layers, so the new base layer node would also have to provide those. Existing widgets will not be aware of BaseLayer nodes, so there will be no need to change those (good for the upcoming release). And the MapPaneOL widget can keep two separate layer lists, one for regular layers and one for base layers. In addition, we need a BaseLayerSwitcher to control the base layer. The BaseLayer nodes in the context could be parsed in a way that the first non-hidden layer will be used as basemap, the others will be set to hidden or just ignored. What will have to be investigated is if it works to add a new layer to the map, set it as base layer, and then remove the existing base layer (as explained by Chris Schmidt in yesterday's meeting). If not, we can still do a newModel/loadModel cycle to destroy the map and re-create it with a new base layer. Steven, do you think you can give this approach a try? Regards, Andreas. On Nov 20, 2007 3:20 PM, Andreas Hocevar <[EMAIL PROTECTED]> wrote: > Hi, > > while all that was said by Steven should be considered for the trunk, > we have to find a reliable solution for the upcoming release. I just > had a little chat with Steven, and we came up with the following > proposal: > > - Base layers are strongly tied with resolutions. Resolutions are > currently in the config, and base layers should also go there. > > - Switching base layers can be done by creating a new > BaseLayerSwitcher widget, which will have a list of base layers > (similar to the OverviewWidget, which has a list of layers for the > overview map). When changing the base layer through this widget, it > will fire a newModel event on the map and put a new baselayer in the > MapPaneOL config. When re-creating the map, the baselayer will be read > from the config. > > - Existing layer control widgets are not affected, they do not know > about base layers > > Please speak up now and tell us what you think about it. > > Regards, > Andreas. > > > On Nov 20, 2007 2:16 PM, Steven M. Ottens <[EMAIL PROTECTED]> 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 > > > ------------------------------------------------------------------------- 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
