Steven, I think this is a good solution for 1.5, but think we can do a better job with OWS Context for future versions.
I think that we should aim to make OWS Context simple and for that I think that <Layer>, <BaseLayer> and <FeatureType> should all be merged. Ie: <Layer service="Google"> <Layer service="WMS"> <Layer service="WFS"> <Layer service="GML"> ... Our applications then decide whether we treat a service as a baselayer or not. Steven M. Ottens wrote: > Hi all, > > After discussing this with Andreas we decided for the following > approach for the 1.5 release: > GMAPS, VE, YMAPS and non WMS-baselayers are only supported in OWSContext > So if we have a standard WMC, we will add a hidden baseLayer, just as > Andreas did already, nothing changes there. It will not be possible to > add google etc on a standard WMC doc. > However if you use OWSContext there's a new LayerType called BaseLayer > where (at least for release 1.5) there can only be 1 in the entire > context doc. It looks like this: > <ows:BaseLayer> > <Server service="Google"/> <!-- the service attribute will decide > what kind of layer it is, in the case of a WMS you will need to add a > resource url --> > <Name>Google Hybrid</Name> <!-- used to set the name of the > baselayer --> > <ows:TileSet> <!-- this is taken from TileCache.py --> > <!-- <ows:resolutions/> --><!-- If prefered you can store you > custom resolutions, for ymap,ve and gmap it's not needed --> > <ows:SRS>EPSG:900913</ows:SRS> <!-- if set to EPSG:900913 it > will automatically switch to sphericalMercator --> > <ows:BoundingBox SRS="EPSG:900913" minx="-20037508" > miny="-20037508" maxx="20037508" maxy="20037508.34"/> <!-- > unfortunately this is currently being ignored, please use the OWS > context bbox--> > <ows:Layers>hybrid</ows:Layers> <!-- here you can choose > aerial/satellite, road/normal or hybrid(default)--> > <!-- <ows:Width/> --> <!-- here you can specify a custom > tilesize, default is 256 --> > <!-- <ows:Format/> --> <!-- here you can specify a custom > format --> > </ows:TileSet> > </ows:BaseLayer> > The BaseLayer will be ignored by all widgets except the MapPaneOL and > if there's no BaseLayer defined it falls back to the empty baseLayer, > the same as with a standard WMC. > > So far I've only tested it with google; tried hybrid, roads and aerial > and it works. > > Please try it and comment on it. > > Regards, > Steven > > > Cameron Shorter wrote: >> 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
