Andreas, you solution sounds good for the 1.5 release. For 1.5 release candidate we want minimal impact changes and it sounds like you have that covered.
Andreas Hocevar 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 > > -- 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
